1 00:00:00,000 --> 00:00:02,490 The following content is provided under a Creative 2 00:00:02,490 --> 00:00:04,059 Commons license. 3 00:00:04,059 --> 00:00:06,360 Your support will help MIT OpenCourseWare 4 00:00:06,360 --> 00:00:10,720 continue to offer high-quality educational resources for free. 5 00:00:10,720 --> 00:00:13,350 To make a donation or view additional materials 6 00:00:13,350 --> 00:00:17,290 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,290 --> 00:00:18,294 at ocw.mit.edu. 8 00:00:25,507 --> 00:00:27,090 HARI BALAKRISHNAN: So, good afternoon. 9 00:00:27,090 --> 00:00:30,280 Continuing our story about networks, 10 00:00:30,280 --> 00:00:32,670 what we've seen so far is a story 11 00:00:32,670 --> 00:00:35,070 where you have a network that you're 12 00:00:35,070 --> 00:00:37,650 trying to connect computers to communicate together. 13 00:00:37,650 --> 00:00:42,600 And we use a network with switches 14 00:00:42,600 --> 00:00:49,770 arranged in some topology to allow us to find 15 00:00:49,770 --> 00:00:51,193 paths between computers. 16 00:00:51,193 --> 00:00:52,860 And so we looked at the routing problem. 17 00:00:52,860 --> 00:00:54,693 We looked at two different routing protocols 18 00:00:54,693 --> 00:00:57,180 to solve that. 19 00:00:57,180 --> 00:00:58,740 Earlier, we talked about this idea 20 00:00:58,740 --> 00:01:00,782 of a packet-switched network and there are queues 21 00:01:00,782 --> 00:01:01,980 in packet-switched networks. 22 00:01:01,980 --> 00:01:05,670 And when traffic comes in too fast, and the queues overflow, 23 00:01:05,670 --> 00:01:07,410 packets may get dropped. 24 00:01:07,410 --> 00:01:10,570 We also looked before at links which have errors on them. 25 00:01:10,570 --> 00:01:12,230 And so if you have errors on links, 26 00:01:12,230 --> 00:01:14,790 then your coding scheme isn't able to correct 27 00:01:14,790 --> 00:01:17,678 for those errors, packets may get lost. 28 00:01:17,678 --> 00:01:19,470 And when we looked at shared media networks 29 00:01:19,470 --> 00:01:21,780 with MAC protocols, depending on the MAC protocol 30 00:01:21,780 --> 00:01:23,820 you use, you may collisions, which means 31 00:01:23,820 --> 00:01:26,980 that packets may get lost. 32 00:01:26,980 --> 00:01:29,850 So what you have is a packet-switched network that 33 00:01:29,850 --> 00:01:32,720 has the property of something called a best-effort network. 34 00:01:37,470 --> 00:01:40,620 And what "best effort" means is that the network 35 00:01:40,620 --> 00:01:43,260 has a few properties that you have to cope with. 36 00:01:43,260 --> 00:01:45,630 The first property of a best-effort network 37 00:01:45,630 --> 00:01:48,270 is that packets may get lost. 38 00:01:54,600 --> 00:01:56,580 The second problem in a best-effort issue that 39 00:01:56,580 --> 00:02:01,848 arises in a best-effort network is that packets have delays, 40 00:02:01,848 --> 00:02:03,015 but the delays are variable. 41 00:02:07,280 --> 00:02:10,259 And particular queuing delays that happen in switches 42 00:02:10,259 --> 00:02:11,880 are variable delays. 43 00:02:14,813 --> 00:02:16,730 The good property of a packet-switched network 44 00:02:16,730 --> 00:02:21,270 is that each packet is treated independently by the network. 45 00:02:21,270 --> 00:02:23,270 So it could be that you have a stream of packets 46 00:02:23,270 --> 00:02:27,740 you want to send, say, belonging to a video stream or a file. 47 00:02:27,740 --> 00:02:30,890 And the sender sends them in some sequential order, 48 00:02:30,890 --> 00:02:32,930 but these packets may take different paths 49 00:02:32,930 --> 00:02:34,207 through the network. 50 00:02:34,207 --> 00:02:36,290 And in fact, there may be switches in the network, 51 00:02:36,290 --> 00:02:39,770 for whatever reason, that may not treat packets in first 52 00:02:39,770 --> 00:02:41,210 in, first out order. 53 00:02:41,210 --> 00:02:42,530 They may reorder packets. 54 00:02:42,530 --> 00:02:44,810 But more generally, packets may take different paths 55 00:02:44,810 --> 00:02:47,870 through the network because the routing protocol might decide 56 00:02:47,870 --> 00:02:51,355 to change the paths on you, and so packets make get reordered. 57 00:02:59,120 --> 00:03:03,350 And the fourth issue in a best-effort network 58 00:03:03,350 --> 00:03:05,990 is that, in fact, packets may get duplicated. 59 00:03:05,990 --> 00:03:09,110 So you may have the same packet show up multiple times 60 00:03:09,110 --> 00:03:11,788 even though it was sent only once for a bunch of reasons. 61 00:03:11,788 --> 00:03:13,580 One of them is that there could be problems 62 00:03:13,580 --> 00:03:16,190 in the implementation of the switches or the nodes 63 00:03:16,190 --> 00:03:18,800 that cause packets to get duplicated. 64 00:03:18,800 --> 00:03:20,360 But it could also be that you may 65 00:03:20,360 --> 00:03:23,840 have a link with a high packet loss rate, 66 00:03:23,840 --> 00:03:25,970 or this may be a shared medium where 67 00:03:25,970 --> 00:03:28,470 you have a MAC protocol that has collisions. 68 00:03:28,470 --> 00:03:30,620 So you may have a retransmission protocol-- 69 00:03:30,620 --> 00:03:35,140 let me try to resend the packet a few times at the lowest layer 70 00:03:35,140 --> 00:03:38,030 over a shared medium or a link. 71 00:03:38,030 --> 00:03:40,712 And sometimes, multiple versions of the multiple copies 72 00:03:40,712 --> 00:03:42,170 of the same packet may get through. 73 00:03:42,170 --> 00:03:45,140 And we'll actually understand why that happens more today. 74 00:03:45,140 --> 00:03:48,860 So packets may get duplicated. 75 00:03:48,860 --> 00:03:52,340 So in a way, a packet-switched network like the internet 76 00:03:52,340 --> 00:03:54,582 is great because it's very easy to build. 77 00:03:54,582 --> 00:03:56,540 And the reason it's easy to build in some sense 78 00:03:56,540 --> 00:03:59,240 is because about the only property that you're 79 00:03:59,240 --> 00:04:01,130 providing from the design of the network 80 00:04:01,130 --> 00:04:05,360 is to tell the endpoints, oh, I might get your package through. 81 00:04:05,360 --> 00:04:07,580 There's no guarantees on anything. 82 00:04:07,580 --> 00:04:09,500 As long as there's some non-zero probability 83 00:04:09,500 --> 00:04:12,380 of getting a packet through from one endpoint to the other, 84 00:04:12,380 --> 00:04:14,300 that's pretty much all it takes to declare 85 00:04:14,300 --> 00:04:17,013 that you have a conforming best-effort network. 86 00:04:17,013 --> 00:04:17,930 So it's easy to build. 87 00:04:17,930 --> 00:04:20,660 But of course, it means that you have all these issues that you 88 00:04:20,660 --> 00:04:22,160 want to deal with if you actually 89 00:04:22,160 --> 00:04:23,397 want to run applications. 90 00:04:23,397 --> 00:04:24,980 So as an example of an application is, 91 00:04:24,980 --> 00:04:27,110 let's say you are trying to download 92 00:04:27,110 --> 00:04:33,650 a web page, or a set of web pictures and text on a page. 93 00:04:33,650 --> 00:04:35,630 What you would like is an abstraction 94 00:04:35,630 --> 00:04:40,550 that you can implement some sort of a scheme you can implement 95 00:04:40,550 --> 00:04:44,270 in the network or in between the endpoints that makes it 96 00:04:44,270 --> 00:04:48,020 so that an application sends a bunch of bytes or packets 97 00:04:48,020 --> 00:04:49,590 or sends a message. 98 00:04:49,590 --> 00:04:52,925 And at the receiving side, you get those bytes reliably. 99 00:04:54,922 --> 00:04:56,880 So that's what we're going to understand today. 100 00:04:56,880 --> 00:04:58,430 We're going to look at today and next week, we're 101 00:04:58,430 --> 00:05:00,260 going to look at how to implement 102 00:05:00,260 --> 00:05:05,810 a protocol that provides reliable data transport. 103 00:05:11,270 --> 00:05:12,770 And the ideas we're going to look at 104 00:05:12,770 --> 00:05:15,950 are probably the ideas that are in the world's 105 00:05:15,950 --> 00:05:18,390 most popular computer program. 106 00:05:18,390 --> 00:05:20,402 It's the most popular in that it runs 107 00:05:20,402 --> 00:05:21,610 in the most number of places. 108 00:05:21,610 --> 00:05:24,890 And it's a protocol called TCP, which 109 00:05:24,890 --> 00:05:28,130 stands for the Transmission Control Protocol. 110 00:05:28,130 --> 00:05:32,420 Now, we're not going through all the gory details of TCP. 111 00:05:32,420 --> 00:05:34,130 We're going to look at a simplified 112 00:05:34,130 --> 00:05:35,330 version of this protocol. 113 00:05:38,790 --> 00:05:40,040 So maybe it's TCP-lite. 114 00:05:42,790 --> 00:05:46,043 But it'll cover the main idea of how 115 00:05:46,043 --> 00:05:47,210 you can achieve reliability. 116 00:05:47,210 --> 00:05:54,660 And this particular program runs on pretty much every computer 117 00:05:54,660 --> 00:05:56,450 and every phone and every little device 118 00:05:56,450 --> 00:05:57,710 that's on the internet today. 119 00:05:57,710 --> 00:05:59,730 So it's really, really popular. 120 00:05:59,730 --> 00:06:03,470 In fact, we're going to start with a simpler protocol that 121 00:06:03,470 --> 00:06:06,410 is a reliable data transport protocol that 122 00:06:06,410 --> 00:06:08,840 isn't used between endpoints. 123 00:06:08,840 --> 00:06:10,357 TCP is used between endpoints. 124 00:06:10,357 --> 00:06:12,440 Now we're going to look at a version of a protocol 125 00:06:12,440 --> 00:06:14,000 that's a simple version that actually 126 00:06:14,000 --> 00:06:16,520 runs in every 802.11 device-- 127 00:06:16,520 --> 00:06:18,730 your laptop, phone, and access points. 128 00:06:18,730 --> 00:06:22,130 So we'll study that protocol too first. 129 00:06:22,130 --> 00:06:24,920 In the context of end to end, between endpoints, 130 00:06:24,920 --> 00:06:26,420 reliable data transport, the problem 131 00:06:26,420 --> 00:06:28,337 is the following-- you have some network here. 132 00:06:31,040 --> 00:06:33,800 It's a best-effort network with those properties. 133 00:06:33,800 --> 00:06:38,170 And what you want is you have an application at one end. 134 00:06:38,170 --> 00:06:40,670 And you have an application at another end 135 00:06:40,670 --> 00:06:43,217 running on some endpoints. 136 00:06:46,350 --> 00:06:48,870 What this system provides that we're 137 00:06:48,870 --> 00:06:51,840 doing this study provides is an abstraction where 138 00:06:51,840 --> 00:06:54,420 you run software here-- 139 00:06:54,420 --> 00:06:56,700 you run software at this end, and all of the stuff 140 00:06:56,700 --> 00:06:59,748 sits on your end node. 141 00:06:59,748 --> 00:07:00,665 This is your endpoint. 142 00:07:04,740 --> 00:07:10,390 And the abstraction provides some nice properties. 143 00:07:10,390 --> 00:07:12,640 The application writes some data in here 144 00:07:12,640 --> 00:07:13,960 at the sender sending in. 145 00:07:13,960 --> 00:07:16,470 So let's call this the sender. 146 00:07:16,470 --> 00:07:18,070 And the other guy's the receiver. 147 00:07:18,070 --> 00:07:20,710 The application writes stuff inside here. 148 00:07:20,710 --> 00:07:22,390 The network is a best-effort network. 149 00:07:22,390 --> 00:07:26,410 And there's some protocol between these two pieces 150 00:07:26,410 --> 00:07:30,490 of software that make sure that no matter what 151 00:07:30,490 --> 00:07:35,560 the network does, what goes up here into the application 152 00:07:35,560 --> 00:07:38,380 is exactly the data that was written 153 00:07:38,380 --> 00:07:42,220 from this application in exactly the same order in which it 154 00:07:42,220 --> 00:07:43,010 was written. 155 00:07:43,010 --> 00:07:46,660 So it provides reliable and in-order delivery 156 00:07:46,660 --> 00:07:54,720 of data, so reliable and in order. 157 00:07:54,720 --> 00:07:56,290 So every piece of data that's written 158 00:07:56,290 --> 00:07:58,690 shows up in exactly the same order exactly once 159 00:07:58,690 --> 00:08:00,010 at the receiver. 160 00:08:00,010 --> 00:08:03,692 And these two ends are called transport. 161 00:08:06,340 --> 00:08:08,590 These two ends constitute the transport layer. 162 00:08:12,160 --> 00:08:15,000 And they [INAUDIBLE] at the end points, OK? 163 00:08:15,000 --> 00:08:18,210 So the application writes in here, the transport protocol 164 00:08:18,210 --> 00:08:21,270 delivers up to the application stuff that's reliable 165 00:08:21,270 --> 00:08:23,600 and in order. 166 00:08:23,600 --> 00:08:26,020 And in particular, it provides the semantics 167 00:08:26,020 --> 00:08:29,500 that you can think of as "exactly once" semantics. 168 00:08:29,500 --> 00:08:31,750 In other words, anything that's sent 169 00:08:31,750 --> 00:08:34,150 is delivered exactly once to the receiver, 170 00:08:34,150 --> 00:08:36,200 and it's delivered in order. 171 00:08:36,200 --> 00:08:39,500 Now, that's the abstraction that TCP as well provides. 172 00:08:39,500 --> 00:08:42,580 And that's the abstraction of our 602 protocol. 173 00:08:42,580 --> 00:08:45,987 It's reliable, in-order, exactly-once delivery. 174 00:08:45,987 --> 00:08:48,070 Now, there are other implementations you can have. 175 00:08:48,070 --> 00:08:50,528 There are protocols you could have that provide reliability 176 00:08:50,528 --> 00:08:51,307 but not in order. 177 00:08:51,307 --> 00:08:53,140 So I'll give you all the data that you send, 178 00:08:53,140 --> 00:08:54,723 but it may show up in different order, 179 00:08:54,723 --> 00:08:56,320 and it's your problem to fix it. 180 00:08:56,320 --> 00:08:58,810 Or you might provide a protocol that provides in order, 181 00:08:58,810 --> 00:09:00,500 but not reliable. 182 00:09:00,500 --> 00:09:05,940 So if I'm doing real-time video conferencing, 183 00:09:05,940 --> 00:09:08,050 say, Skype, Skype would probably want 184 00:09:08,050 --> 00:09:11,770 to provide a protocol that's in order but not reliable, 185 00:09:11,770 --> 00:09:13,870 because if I speak, you'd like to actually get 186 00:09:13,870 --> 00:09:17,480 those things into the Skype application in order. 187 00:09:17,480 --> 00:09:19,270 But it's not really required that it 188 00:09:19,270 --> 00:09:24,370 be reliable because if a message shows up, say, more than 100 189 00:09:24,370 --> 00:09:27,020 or 200 milliseconds after I spoke it, 190 00:09:27,020 --> 00:09:28,645 it's going to distort the conversation. 191 00:09:28,645 --> 00:09:30,353 It's not going to be intelligible to you. 192 00:09:30,353 --> 00:09:32,050 And the human ear is wonderful at-- 193 00:09:32,050 --> 00:09:34,988 the human brain is wonderful at dealing with some clippiness 194 00:09:34,988 --> 00:09:35,530 in the voice. 195 00:09:35,530 --> 00:09:37,113 You know, occasional packets get lost. 196 00:09:37,113 --> 00:09:38,503 It's not the end of the world. 197 00:09:38,503 --> 00:09:40,420 So there are lots of interesting applications. 198 00:09:40,420 --> 00:09:43,360 But in order is useful, but not perfectly reliable. 199 00:09:43,360 --> 00:09:45,920 Applications where reliable is useful, but not perfectly 200 00:09:45,920 --> 00:09:46,420 in order. 201 00:09:46,420 --> 00:09:48,430 BitTorrent would be an example of that. 202 00:09:48,430 --> 00:09:50,950 An application where eventually you want all of those movies 203 00:09:50,950 --> 00:09:51,670 that you're trying to get. 204 00:09:51,670 --> 00:09:53,260 But who cares what order they come in? 205 00:09:53,260 --> 00:09:54,802 You're not going to start watching it 206 00:09:54,802 --> 00:09:56,260 until the whole file is assembled. 207 00:09:56,260 --> 00:09:59,423 And so the protocol that BitTorrent uses in effect-- 208 00:09:59,423 --> 00:10:00,590 it's a complicated protocol. 209 00:10:00,590 --> 00:10:01,780 It's not point to point. 210 00:10:01,780 --> 00:10:03,490 But in effect, it provides reliability 211 00:10:03,490 --> 00:10:05,140 without worrying about ordering. 212 00:10:05,140 --> 00:10:07,010 So there's lots of combinations. 213 00:10:07,010 --> 00:10:08,830 The combination we care about is reliable, 214 00:10:08,830 --> 00:10:11,288 in order, essentially giving you the illusion that you have 215 00:10:11,288 --> 00:10:13,930 a circuit between the two endpoints, a wire 216 00:10:13,930 --> 00:10:16,360 between the two endpoints, OK? 217 00:10:16,360 --> 00:10:17,530 So is the abstraction clear? 218 00:10:17,530 --> 00:10:20,663 Everyone understands what we're trying to solve? 219 00:10:20,663 --> 00:10:22,330 And in between this, just think, there's 220 00:10:22,330 --> 00:10:24,450 an adversary or some network in the middle 221 00:10:24,450 --> 00:10:26,140 that you sent packets, and the thing 222 00:10:26,140 --> 00:10:27,520 is just throwing packets away. 223 00:10:27,520 --> 00:10:29,645 And every once in a while, just for the heck of it, 224 00:10:29,645 --> 00:10:33,040 it decides to delay a packet for a long time. 225 00:10:33,040 --> 00:10:34,870 And every once in a while, it decides 226 00:10:34,870 --> 00:10:38,170 to send packets along different paths. 227 00:10:38,170 --> 00:10:40,265 And your job is to deal with all of that 228 00:10:40,265 --> 00:10:42,390 and design the sending side and the receiving sides 229 00:10:42,390 --> 00:10:44,740 so that stuff still shows up reliably 230 00:10:44,740 --> 00:10:47,507 and in the same order in which it was sent. 231 00:10:47,507 --> 00:10:49,340 So we're going to try to solve this problem. 232 00:10:49,340 --> 00:10:52,160 We're going to solve it first by coming up with a protocol. 233 00:10:52,160 --> 00:10:54,490 It has a nice name to it called stop and wait. 234 00:10:54,490 --> 00:10:56,710 It's a very simple idea. 235 00:10:56,710 --> 00:11:00,870 And this will be a protocol that works, but it's slow. 236 00:11:00,870 --> 00:11:02,120 But the good news is it works. 237 00:11:02,120 --> 00:11:02,662 It's correct. 238 00:11:02,662 --> 00:11:04,540 It gives the semantics we want. 239 00:11:04,540 --> 00:11:07,480 And then we'll try to improve its performance. 240 00:11:07,480 --> 00:11:08,590 It's a very simple idea. 241 00:11:08,590 --> 00:11:10,820 I'm sure you have-- just think about this for three minutes. 242 00:11:10,820 --> 00:11:13,100 You'll come up with something that looks like this. 243 00:11:13,100 --> 00:11:15,860 You just take the message you want to send, whatever file, 244 00:11:15,860 --> 00:11:17,680 stream, or video, whatever it is, 245 00:11:17,680 --> 00:11:19,240 and break it up into packets. 246 00:11:19,240 --> 00:11:21,515 So far, there's nothing new here. 247 00:11:21,515 --> 00:11:23,890 The main first idea is we're going to number every packet 248 00:11:23,890 --> 00:11:25,580 with a sequence number. 249 00:11:25,580 --> 00:11:29,050 So that's what's shown here as "Data 1," "Data 2," "Data 3," 250 00:11:29,050 --> 00:11:29,630 and so forth. 251 00:11:29,630 --> 00:11:31,963 So we're going to use a sequence number on every packet. 252 00:11:34,927 --> 00:11:37,510 Now, again, there are many ways to implement sequence numbers. 253 00:11:37,510 --> 00:11:41,110 The way that's the simplest and most conceptually clean 254 00:11:41,110 --> 00:11:42,950 is every packet has a sequence number that 255 00:11:42,950 --> 00:11:46,510 increments by 1 for every subsequent packet that's sent. 256 00:11:46,510 --> 00:11:52,240 And you might initially start the sequence numbering 257 00:11:52,240 --> 00:11:53,680 at 0 or 1 or whatever. 258 00:11:53,680 --> 00:11:55,780 The sender and the receiver have to agree on that. 259 00:11:55,780 --> 00:11:57,820 Now, in reality, TCP in the real world 260 00:11:57,820 --> 00:11:59,230 is a little more complicated. 261 00:11:59,230 --> 00:12:03,622 TCP provides sequence numbering by numbering the bytes 262 00:12:03,622 --> 00:12:05,080 with the byte offset in the stream. 263 00:12:05,080 --> 00:12:07,630 So if you send a packet which is 25 bytes, 264 00:12:07,630 --> 00:12:09,847 and the next packet is 200 bytes, 265 00:12:09,847 --> 00:12:11,680 the first packet is going to have a sequence 266 00:12:11,680 --> 00:12:13,150 number of, let's say, 0. 267 00:12:13,150 --> 00:12:15,940 The second packet's going to have a sequence number of 26 268 00:12:15,940 --> 00:12:18,760 because it numbers the starting of the byte offset. 269 00:12:18,760 --> 00:12:21,330 But these are all details that to first order, 270 00:12:21,330 --> 00:12:22,887 we don't have to really worry about. 271 00:12:22,887 --> 00:12:24,970 The important point is there is a sequence number. 272 00:12:24,970 --> 00:12:27,130 And a sequence number is a unique identifier 273 00:12:27,130 --> 00:12:28,210 for the packet. 274 00:12:28,210 --> 00:12:31,270 In other words, if I later send a packet with the same sequence 275 00:12:31,270 --> 00:12:34,870 number, I have to guarantee that the material inside the packet 276 00:12:34,870 --> 00:12:37,010 is the same as it was before. 277 00:12:37,010 --> 00:12:39,220 So the assumption is that this is a unique identifier 278 00:12:39,220 --> 00:12:41,840 for the contents of the packet. 279 00:12:41,840 --> 00:12:43,630 So it's a unique identifier. 280 00:12:43,630 --> 00:12:46,810 We want to use it for some other set of bytes. 281 00:12:46,810 --> 00:12:49,060 We'll always use it again for the same set of bytes 282 00:12:49,060 --> 00:12:53,405 if we ever retransmit a packet with the same sequence number. 283 00:12:53,405 --> 00:12:55,780 When the receiver gets the packet with a certain sequence 284 00:12:55,780 --> 00:12:57,670 number, it does what the post office does 285 00:12:57,670 --> 00:12:59,460 if you send registered post-- 286 00:12:59,460 --> 00:13:01,720 you turn around, and you send an acknowledgment. 287 00:13:01,720 --> 00:13:05,350 And to allow the sender to know which packet's 288 00:13:05,350 --> 00:13:07,793 being acknowledged, you stick in the sequence number 289 00:13:07,793 --> 00:13:09,460 of the packet that's being acknowledged. 290 00:13:09,460 --> 00:13:11,080 So you send sequence 1. 291 00:13:11,080 --> 00:13:12,340 Data 1, you get ACK 1. 292 00:13:12,340 --> 00:13:15,880 Data 2, you get ACK 2, and everything is wonderful. 293 00:13:15,880 --> 00:13:19,260 It's easy, easy protocol. 294 00:13:19,260 --> 00:13:22,100 So what happens when a packet's lost, this data is lost? 295 00:13:22,100 --> 00:13:23,600 What's going to happen is the sender 296 00:13:23,600 --> 00:13:25,640 is not going to get an acknowledgment. 297 00:13:25,640 --> 00:13:29,600 And after some period of time called the timeout, 298 00:13:29,600 --> 00:13:32,570 the sender decides that it wants to retry that packet. 299 00:13:32,570 --> 00:13:34,080 And it tries to resend the packet. 300 00:13:34,080 --> 00:13:35,935 And if it works, it gets an acknowledgment. 301 00:13:35,935 --> 00:13:37,310 When it gets that acknowledgment, 302 00:13:37,310 --> 00:13:40,222 that's when it goes and sends the next packet. 303 00:13:40,222 --> 00:13:41,930 So the property of stop-and-wait protocol 304 00:13:41,930 --> 00:13:45,483 is that you send a packet only after you 305 00:13:45,483 --> 00:13:46,400 get an acknowledgment. 306 00:13:46,400 --> 00:13:48,470 You sent packet k plus 1 only after you get 307 00:13:48,470 --> 00:13:50,960 an acknowledgment for packet k. 308 00:13:50,960 --> 00:13:53,390 If you don't get an acknowledgment for packet k, 309 00:13:53,390 --> 00:13:55,820 you wait for a period of time called a timeout. 310 00:13:55,820 --> 00:13:58,985 And after that timeout elapses, you 311 00:13:58,985 --> 00:14:03,230 retransmit the packet that you considered was lost, 312 00:14:03,230 --> 00:14:05,130 that you thought was lost. 313 00:14:05,130 --> 00:14:06,810 OK, simple. 314 00:14:06,810 --> 00:14:10,475 Now, is this protocol reliable? 315 00:14:10,475 --> 00:14:11,850 And when I ask that question, you 316 00:14:11,850 --> 00:14:15,150 have to assume that the network may drop and reorder and do 317 00:14:15,150 --> 00:14:16,380 whatever it does to packets. 318 00:14:16,380 --> 00:14:18,900 But there's always a non-zero probability 319 00:14:18,900 --> 00:14:21,090 that a packet or data packet or acknowledgment 320 00:14:21,090 --> 00:14:24,285 packet sent on the network has a non-zero probability 321 00:14:24,285 --> 00:14:25,410 of reaching the other side. 322 00:14:25,410 --> 00:14:27,820 Because if the probability of packet loss is 1, 323 00:14:27,820 --> 00:14:29,670 now no one can help us. 324 00:14:29,670 --> 00:14:31,380 So is this protocol reliable? 325 00:14:34,210 --> 00:14:34,720 OK. 326 00:14:34,720 --> 00:14:37,040 Is this protocol in order? 327 00:14:37,040 --> 00:14:38,290 It is in order in the way of-- 328 00:14:38,290 --> 00:14:40,630 I'm not actually describing what the receiver does. 329 00:14:40,630 --> 00:14:44,597 But I should tell you that the receiver's semantics here 330 00:14:44,597 --> 00:14:46,180 are when the receiver gets the packet, 331 00:14:46,180 --> 00:14:50,150 it delivers it to the application. 332 00:14:50,150 --> 00:14:53,930 Now, if you turn out that this protocol is not necessarily 333 00:14:53,930 --> 00:14:57,050 in order the way I described it-- and I'll come back to why. 334 00:14:57,050 --> 00:14:59,207 But so far, it looks like the protocol is in order. 335 00:14:59,207 --> 00:15:01,040 But remember what I said about the receiver? 336 00:15:01,040 --> 00:15:03,860 When the receiver gets a data packet, 337 00:15:03,860 --> 00:15:08,060 it delivers it up to the application. 338 00:15:08,060 --> 00:15:11,225 So is the protocol potentially not in order? 339 00:15:11,225 --> 00:15:12,350 It's not actually in order. 340 00:15:12,350 --> 00:15:13,267 We'll get back to why. 341 00:15:13,267 --> 00:15:14,110 You have a question? 342 00:15:14,110 --> 00:15:15,610 AUDIENCE: Yeah, I was just wondering 343 00:15:15,610 --> 00:15:17,870 if the receiver gets a data packet 344 00:15:17,870 --> 00:15:20,378 and then tries to send an acknowledgement back, 345 00:15:20,378 --> 00:15:25,414 if the acknowledgement gets wrong, I guess, 346 00:15:25,414 --> 00:15:27,157 the sender will resend data. 347 00:15:27,157 --> 00:15:30,080 Does the receiver then compare to figure out? 348 00:15:30,080 --> 00:15:32,330 HARI BALAKRISHNAN: Right, so I haven't specified that. 349 00:15:32,330 --> 00:15:35,647 And you are one step ahead of-- 350 00:15:35,647 --> 00:15:36,980 you're at the next picture here. 351 00:15:36,980 --> 00:15:38,840 What happens in this case? 352 00:15:38,840 --> 00:15:40,300 You get a duplicate packet. 353 00:15:40,300 --> 00:15:42,500 And in fact, that's precisely for this reason 354 00:15:42,500 --> 00:15:44,000 that this protocol is not actually-- 355 00:15:44,000 --> 00:15:45,380 it's kind of in order, but in order 356 00:15:45,380 --> 00:15:48,020 means that you deliver packets in the same order in which they 357 00:15:48,020 --> 00:15:48,740 were sent. 358 00:15:48,740 --> 00:15:50,657 And in the way I've described the description, 359 00:15:50,657 --> 00:15:52,610 given the description of this protocol, 360 00:15:52,610 --> 00:15:56,000 this protocol does not provide exactly one semantics, right? 361 00:15:56,000 --> 00:15:57,597 It provides at least one semantics. 362 00:15:57,597 --> 00:15:59,930 In other words, every package is delivered at least once 363 00:15:59,930 --> 00:16:01,023 to the application. 364 00:16:01,023 --> 00:16:03,440 And what you would like us to deliver every packet exactly 365 00:16:03,440 --> 00:16:05,430 once to the application in order. 366 00:16:05,430 --> 00:16:08,240 So what would you have to do at the receiver in the software 367 00:16:08,240 --> 00:16:12,620 that you write and the receiver transport to take the same idea 368 00:16:12,620 --> 00:16:17,240 and make it be a reliable, in-order, exactly-once 369 00:16:17,240 --> 00:16:18,930 protocol? 370 00:16:18,930 --> 00:16:19,430 Yes? 371 00:16:19,430 --> 00:16:22,420 AUDIENCE: Loop up if you received that sequence number. 372 00:16:22,420 --> 00:16:22,960 HARI BALAKRISHNAN: Sorry, say again. 373 00:16:22,960 --> 00:16:25,520 AUDIENCE: Look up if you've received that sequence number. 374 00:16:25,520 --> 00:16:27,290 HARI BALAKRISHNAN: Look up if we received that sequence number. 375 00:16:27,290 --> 00:16:28,450 AUDIENCE: I think that's right. 376 00:16:28,450 --> 00:16:29,450 HARI BALAKRISHNAN: Good. 377 00:16:29,450 --> 00:16:31,745 So one implementation is you perhaps keep 378 00:16:31,745 --> 00:16:33,620 track of all the sequence numbers you've ever 379 00:16:33,620 --> 00:16:35,665 received and delivered up to the application. 380 00:16:35,665 --> 00:16:37,040 If the new guy comes in, you look 381 00:16:37,040 --> 00:16:41,457 and see if it's in your list, and deliver it if not. 382 00:16:41,457 --> 00:16:42,290 You could do better. 383 00:16:42,290 --> 00:16:43,498 You have to do all that work. 384 00:16:47,200 --> 00:16:49,450 You have to keep track of the list of all the sequence 385 00:16:49,450 --> 00:16:51,400 numbers you've ever received in order for this protocol 386 00:16:51,400 --> 00:16:51,900 to work. 387 00:16:51,900 --> 00:16:53,915 AUDIENCE: [INAUDIBLE] 388 00:16:53,915 --> 00:16:56,040 HARI BALAKRISHNAN: Yeah, is it enough to keep track 389 00:16:56,040 --> 00:16:57,873 of simply the very last one you've delivered 390 00:16:57,873 --> 00:17:00,790 and also guarantee that you'll only deliver stuff in order? 391 00:17:00,790 --> 00:17:05,310 So if you get up to packet number 17 and you now get 18, 392 00:17:05,310 --> 00:17:06,810 you deliver it up to the application 393 00:17:06,810 --> 00:17:09,640 and update your counter to be set from 17 to 18 394 00:17:09,640 --> 00:17:12,510 of the last sequence number you've delivered. 395 00:17:12,510 --> 00:17:14,940 If your last sequence number delivered in order is 17, 396 00:17:14,940 --> 00:17:17,357 and you get 16, throw it out. 397 00:17:17,357 --> 00:17:18,690 If you get 17, you throw it out. 398 00:17:18,690 --> 00:17:21,667 If you get anything-- if you get 19, which probably shouldn't 399 00:17:21,667 --> 00:17:23,250 happen in this protocol unless there's 400 00:17:23,250 --> 00:17:25,845 a mistake in the implementation that they're sending in, 401 00:17:25,845 --> 00:17:28,800 if the last sequence number I got was 17, 402 00:17:28,800 --> 00:17:30,030 can the sender send 19? 403 00:17:33,411 --> 00:17:34,100 AUDIENCE: No. 404 00:17:34,100 --> 00:17:35,225 HARI BALAKRISHNAN: Why not? 405 00:17:35,225 --> 00:17:37,350 AUDIENCE: Because we have 17 acknowledgements [INAUDIBLE].. 406 00:17:37,350 --> 00:17:38,280 HARI BALAKRISHNAN: Because-- that's right. 407 00:17:38,280 --> 00:17:40,510 So unless there's a bug in either side of implementation, 408 00:17:40,510 --> 00:17:42,135 which, trust me, when you implement it, 409 00:17:42,135 --> 00:17:44,070 you'll probably end up having some bugs, 410 00:17:44,070 --> 00:17:45,960 and you'd know something is amiss. 411 00:17:45,960 --> 00:17:48,002 But there are these invariants that have to hold. 412 00:17:48,002 --> 00:17:50,490 The sender can send k plus 1 only if it gets an ACK for k. 413 00:17:50,490 --> 00:17:53,310 The sender gets an ACK for k only if the receiver got k. 414 00:17:53,310 --> 00:17:56,850 And therefore, if the sender's last in-order sequence number 415 00:17:56,850 --> 00:18:00,430 received and delivered the application was 17, 416 00:18:00,430 --> 00:18:03,760 it can't actually get a 19 in a correctly implemented protocol. 417 00:18:03,760 --> 00:18:05,810 But if it does, because in the real world, 418 00:18:05,810 --> 00:18:07,230 you don't know who the heck wrote the sending side. 419 00:18:07,230 --> 00:18:08,550 You might have done your receiver, 420 00:18:08,550 --> 00:18:10,230 and the sender might have been done by, 421 00:18:10,230 --> 00:18:11,397 oh, I don't know, Microsoft. 422 00:18:11,397 --> 00:18:13,770 And it may have an issue with it, or Apple, or whoever. 423 00:18:13,770 --> 00:18:15,520 I mean, you don't want to trust it, right? 424 00:18:15,520 --> 00:18:18,990 So you have to be careful about making sure that you might 425 00:18:18,990 --> 00:18:20,670 want to assume the protocols-- 426 00:18:20,670 --> 00:18:22,140 you don't want assume necessarily 427 00:18:22,140 --> 00:18:25,080 that the other guys implemented the protocol right because he 428 00:18:25,080 --> 00:18:26,170 might not have. 429 00:18:26,170 --> 00:18:27,730 And so, who knows what might happen? 430 00:18:27,730 --> 00:18:31,410 So your rule as the receiver is to rigidly obey 431 00:18:31,410 --> 00:18:34,150 whatever the discipline is, which is you deliver up 432 00:18:34,150 --> 00:18:37,470 a packet exactly in order. 433 00:18:37,470 --> 00:18:41,820 OK, so we wanted exactly-once semantics. 434 00:18:41,820 --> 00:18:44,580 And the way you get that is you get that 435 00:18:44,580 --> 00:18:47,340 by keeping track of the very last sequence number 436 00:18:47,340 --> 00:18:48,695 that you received. 437 00:18:48,695 --> 00:18:51,070 So this protocol-- so the first idea is sequence numbers. 438 00:18:51,070 --> 00:18:58,020 The second protocol is a retransmission after a timeout. 439 00:19:00,760 --> 00:19:03,160 Now, how big should this timeout be? 440 00:19:03,160 --> 00:19:06,010 This whole protocol rests on this magic timeout. 441 00:19:06,010 --> 00:19:06,760 What should it be? 442 00:19:06,760 --> 00:19:08,260 15, 17? 443 00:19:08,260 --> 00:19:10,815 What are the units of the timeout? 444 00:19:10,815 --> 00:19:12,690 Actually, what are the units of this timeout? 445 00:19:15,690 --> 00:19:16,350 It's time. 446 00:19:16,350 --> 00:19:18,690 So it's, like, seconds or milliseconds or something. 447 00:19:18,690 --> 00:19:21,009 How big should it be? 448 00:19:21,009 --> 00:19:21,981 AUDIENCE: [INAUDIBLE] 449 00:19:21,981 --> 00:19:22,981 HARI BALAKRISHNAN: What? 450 00:19:22,981 --> 00:19:23,970 AUDIENCE: 5 milliseconds. 451 00:19:23,970 --> 00:19:25,387 HARI BALAKRISHNAN: 5 milliseconds? 452 00:19:25,387 --> 00:19:27,360 AUDIENCE: [INAUDIBLE] milliseconds. 453 00:19:27,360 --> 00:19:28,490 AUDIENCE: Units [INAUDIBLE] milliseconds. 454 00:19:28,490 --> 00:19:29,890 HARI BALAKRISHNAN: Yeah, units are seconds or milliseconds. 455 00:19:29,890 --> 00:19:30,390 Good. 456 00:19:30,390 --> 00:19:33,855 But how would you pick it? 457 00:19:33,855 --> 00:19:35,490 AUDIENCE: You know the round-trip time. 458 00:19:35,490 --> 00:19:36,190 HARI BALAKRISHNAN: OK, good. 459 00:19:36,190 --> 00:19:37,107 So that's a good idea. 460 00:19:37,107 --> 00:19:39,190 There's this thing I've written on the left called 461 00:19:39,190 --> 00:19:40,270 the round-trip time. 462 00:19:40,270 --> 00:19:41,895 But you don't know the round-trip time, 463 00:19:41,895 --> 00:19:43,870 but you could measure the round-trip time. 464 00:19:43,870 --> 00:19:46,630 And I'll talk about how you measure it a little bit later. 465 00:19:46,630 --> 00:19:49,960 But it's important to realize that if you make the timeout be 466 00:19:49,960 --> 00:19:51,650 smaller than the round-trip time, 467 00:19:51,650 --> 00:19:54,490 where the round-trip time is defined as the time at which 468 00:19:54,490 --> 00:19:57,280 you sent a packet to when you got an acknowledgment for that 469 00:19:57,280 --> 00:19:57,845 packet-- 470 00:19:57,845 --> 00:20:00,220 if you make the timeout smaller than the round-trip time, 471 00:20:00,220 --> 00:20:02,520 what happens in this protocol? 472 00:20:02,520 --> 00:20:06,565 Let me first ask, is the protocol still correct? 473 00:20:06,565 --> 00:20:08,230 By correct, I mean, does it provide 474 00:20:08,230 --> 00:20:10,590 reliable, in-order delivery? 475 00:20:10,590 --> 00:20:15,280 OK, it's correct, because that correctness does not rest 476 00:20:15,280 --> 00:20:16,680 on how we pick the timeout. 477 00:20:16,680 --> 00:20:19,180 However, what is the problem with making the timeout smaller 478 00:20:19,180 --> 00:20:20,055 than round-trip time? 479 00:20:20,055 --> 00:20:22,188 AUDIENCE: [INAUDIBLE] 480 00:20:22,188 --> 00:20:24,730 HARI BALAKRISHNAN: Yeah, if this protocol's going to be here, 481 00:20:24,730 --> 00:20:26,290 you're going to be retransmitting 482 00:20:26,290 --> 00:20:28,840 and retransmitting and using up a lot more of the network's 483 00:20:28,840 --> 00:20:32,217 resources than you need to in order for you to actually get 484 00:20:32,217 --> 00:20:33,550 your protocol to work correctly. 485 00:20:33,550 --> 00:20:35,842 And you might, if the time out is really, really small, 486 00:20:35,842 --> 00:20:38,060 you would probably congest the network. 487 00:20:38,060 --> 00:20:40,068 OK, so the timeout has to be bigger 488 00:20:40,068 --> 00:20:41,110 than the round-trip time. 489 00:20:41,110 --> 00:20:42,777 The trouble in a packet-switched network 490 00:20:42,777 --> 00:20:45,480 is that delays are variable in a best-effort network. 491 00:20:45,480 --> 00:20:47,105 And, in fact, packets may be reordered. 492 00:20:47,105 --> 00:20:49,690 There may be weird things going on in the network, which 493 00:20:49,690 --> 00:20:52,107 means that the round-trip times are actually not constant. 494 00:20:52,107 --> 00:20:53,170 They vary with time. 495 00:20:53,170 --> 00:20:54,520 They vary with other traffic. 496 00:20:54,520 --> 00:20:57,140 They vary with lots of other factors. 497 00:20:57,140 --> 00:21:00,310 And so what you want is an adaptive method that 498 00:21:00,310 --> 00:21:02,230 would measure the round-trip time, 499 00:21:02,230 --> 00:21:04,390 estimate the round-trip time, and then come up 500 00:21:04,390 --> 00:21:07,210 with some sort of an algorithm to compute or to set 501 00:21:07,210 --> 00:21:09,850 the timeout as a function of the observations 502 00:21:09,850 --> 00:21:11,260 of the round-trip time. 503 00:21:11,260 --> 00:21:13,630 I'll get back to that later on today. 504 00:21:13,630 --> 00:21:16,930 And we'll also talk about this in recitation tomorrow. 505 00:21:16,930 --> 00:21:19,180 It's actually a very nice application of a very simple 506 00:21:19,180 --> 00:21:20,330 low-pass filter. 507 00:21:20,330 --> 00:21:22,270 So we'll actually come back to this idea. 508 00:21:22,270 --> 00:21:24,520 But what I want to you to have in your head 509 00:21:24,520 --> 00:21:26,740 right now is this idea that there's a timeout. 510 00:21:26,740 --> 00:21:28,760 And the timeout has to be-- which I'll call 511 00:21:28,760 --> 00:21:32,020 RTO for Retransmission TimeOut. 512 00:21:32,020 --> 00:21:35,320 We have this idea that our retransmission timeout 513 00:21:35,320 --> 00:21:39,130 has to be bigger than the round-trip time, OK? 514 00:21:39,130 --> 00:21:40,592 So what I need to tell you still is 515 00:21:40,592 --> 00:21:42,550 how to measure and estimate the round-trip time 516 00:21:42,550 --> 00:21:44,758 and how to use these estimates of the round-trip time 517 00:21:44,758 --> 00:21:46,420 to pick the timeout. 518 00:21:46,420 --> 00:21:49,360 But let's subcontract that problem to someone. 519 00:21:49,360 --> 00:21:51,730 Let's say that there's the black box that 520 00:21:51,730 --> 00:21:53,630 will tell you what the timeout should be, 521 00:21:53,630 --> 00:21:56,270 and now you have this protocol. 522 00:21:56,270 --> 00:21:58,990 So assuming we have that black box and someone telling you 523 00:21:58,990 --> 00:22:01,930 the retransmission timeout, what I would like to do now 524 00:22:01,930 --> 00:22:04,300 is to spend some time telling you 525 00:22:04,300 --> 00:22:06,440 how well this protocol works. 526 00:22:06,440 --> 00:22:09,520 I'd like to understand what is the throughput, which 527 00:22:09,520 --> 00:22:12,170 is the data rate that you get if you're 528 00:22:12,170 --> 00:22:14,750 on the stop-and-wait protocol. 529 00:22:14,750 --> 00:22:16,420 So that's what I want to do now-- 530 00:22:16,420 --> 00:22:20,350 throughput of stop and wait. 531 00:22:24,220 --> 00:22:25,903 So the input here is-- 532 00:22:25,903 --> 00:22:27,820 I'm going to assume a very, very simple model. 533 00:22:27,820 --> 00:22:30,690 I'm going to assume for a minute that the round-trip time 534 00:22:30,690 --> 00:22:32,890 doesn't change a whole lot. 535 00:22:32,890 --> 00:22:34,900 This is a very simplifying assumption, 536 00:22:34,900 --> 00:22:37,840 but there's some average round-trip time. 537 00:22:37,840 --> 00:22:41,767 I'm going to assume that the round-trip time is RTT. 538 00:22:41,767 --> 00:22:43,600 The same result holds if the round-trip time 539 00:22:43,600 --> 00:22:45,400 varies, but just simple model. 540 00:22:45,400 --> 00:22:47,540 Let's just assume the round-trip time is fixed. 541 00:22:47,540 --> 00:22:49,510 And let's assume that somebody tells us what 542 00:22:49,510 --> 00:22:51,440 the retransmission timeout is. 543 00:22:51,440 --> 00:22:53,080 And I need one more parameter. 544 00:22:53,080 --> 00:22:58,360 I'm going to assume that I know the network's packet loss 545 00:22:58,360 --> 00:23:02,110 rate because intuitively, if the network's packet loss 546 00:23:02,110 --> 00:23:03,600 rate is zero-- 547 00:23:03,600 --> 00:23:05,130 that is, no packets are lost. 548 00:23:05,130 --> 00:23:07,690 No data packets, no acknowledgments are lost-- 549 00:23:07,690 --> 00:23:09,400 then you would expect this protocol 550 00:23:09,400 --> 00:23:13,430 has higher throughput than if packets were lost, right? 551 00:23:13,430 --> 00:23:15,082 If the packet loss rate is 50%, you 552 00:23:15,082 --> 00:23:16,540 would expect that what would happen 553 00:23:16,540 --> 00:23:19,660 is, well, half the packets or ACKs are getting lost, 554 00:23:19,660 --> 00:23:21,610 which means you have to retransmit the packet. 555 00:23:21,610 --> 00:23:23,318 And every time you retransmit the packet, 556 00:23:23,318 --> 00:23:25,360 the protocol comes to a wait. 557 00:23:25,360 --> 00:23:28,672 And you have to wait until the timeout happens. 558 00:23:28,672 --> 00:23:30,130 So the bigger the packet loss rate, 559 00:23:30,130 --> 00:23:32,270 you would expect the protocol to be slower. 560 00:23:32,270 --> 00:23:36,130 So I'm going to assume that we have RTT and RTO. 561 00:23:36,130 --> 00:23:47,070 And we have a packet loss rate of L. So what does that mean? 562 00:23:47,070 --> 00:23:49,790 What it means is that if I send a large number of packets 563 00:23:49,790 --> 00:23:54,065 to the network, a fraction, L, of them will get lost. 564 00:23:54,065 --> 00:23:55,940 And I'll just assume in the simplifying model 565 00:23:55,940 --> 00:23:58,560 that the packet losses are independent. 566 00:23:58,560 --> 00:24:00,160 So they're sort of Bernoulli losses. 567 00:24:00,160 --> 00:24:02,660 You know, every packet gets lost independently 568 00:24:02,660 --> 00:24:04,850 with some probability. 569 00:24:04,850 --> 00:24:08,150 Now, I also will assume in this protocol-- 570 00:24:08,150 --> 00:24:10,310 does it matter to the performance of the protocol 571 00:24:10,310 --> 00:24:13,640 if the data packet is lost or if the ACK packet is lost? 572 00:24:16,730 --> 00:24:17,480 It doesn't matter. 573 00:24:17,480 --> 00:24:19,772 As far as the sender's-- and this is an important point 574 00:24:19,772 --> 00:24:20,420 to understand. 575 00:24:20,420 --> 00:24:22,340 As far as the sender is concerned, 576 00:24:22,340 --> 00:24:24,860 if a timeout happens, it has no way 577 00:24:24,860 --> 00:24:26,780 of knowing whether the timeout happened 578 00:24:26,780 --> 00:24:29,570 because the data was lost or because the ACK was lost. 579 00:24:29,570 --> 00:24:31,750 This is, like, absolutely-- the receiver knows. 580 00:24:31,750 --> 00:24:33,170 Or actually, the receiver doesn't 581 00:24:33,170 --> 00:24:34,760 know if a timeout happened, but the receiver 582 00:24:34,760 --> 00:24:36,677 does know whether it got a data packet or not. 583 00:24:36,677 --> 00:24:38,840 But the sender-- the only thing it's acting on 584 00:24:38,840 --> 00:24:40,070 is the absence of an ACK. 585 00:24:40,070 --> 00:24:43,170 And the absence of an ACK indicates either 586 00:24:43,170 --> 00:24:45,170 that the data was lost or that the ACK was lost, 587 00:24:45,170 --> 00:24:47,240 and it has no idea which. 588 00:24:47,240 --> 00:24:50,720 Therefore, we could assume for this analysis 589 00:24:50,720 --> 00:24:53,630 that this packet loss rate of L is actually 590 00:24:53,630 --> 00:24:55,370 a bidirectional packet loss rate. 591 00:24:58,550 --> 00:25:02,240 What I mean by that is L is the probability that either a data 592 00:25:02,240 --> 00:25:06,390 packet is lost, or its ACK was lost, OK? 593 00:25:06,390 --> 00:25:08,460 Now, if I give you the one-way loss probability, 594 00:25:08,460 --> 00:25:10,030 you can do the calculation. 595 00:25:10,030 --> 00:25:11,898 That's a probability calculation to find out 596 00:25:11,898 --> 00:25:14,190 what is the probability that either the packet was lost 597 00:25:14,190 --> 00:25:15,090 or the data was lost. 598 00:25:15,090 --> 00:25:16,410 That's an easy calculation. 599 00:25:16,410 --> 00:25:18,970 But let me just assume that the probability that either 600 00:25:18,970 --> 00:25:21,840 the packet was lost, data packet was lost, or its ACK was lost, 601 00:25:21,840 --> 00:25:22,980 is L. 602 00:25:22,980 --> 00:25:25,633 So given these numbers, what I want to do is, 603 00:25:25,633 --> 00:25:28,050 given these things, I want to know what the throughput is. 604 00:25:30,840 --> 00:25:37,030 In other words, how many packets per second 605 00:25:37,030 --> 00:25:39,880 am I transmitting, am I able to transmit, 606 00:25:39,880 --> 00:25:42,178 or am I able to receive at the receiver? 607 00:25:42,178 --> 00:25:44,470 So if you want to look at what happens in this picture, 608 00:25:44,470 --> 00:25:49,530 if you draw time like that-- 609 00:25:49,530 --> 00:25:54,310 you send a packet, and maybe you get an ACK here. 610 00:25:54,310 --> 00:25:56,510 So D1, A1. 611 00:25:56,510 --> 00:26:01,690 You send D2 immediately. 612 00:26:01,690 --> 00:26:04,420 And you get A2 after some time. 613 00:26:04,420 --> 00:26:06,880 And maybe you have a timeout. 614 00:26:06,880 --> 00:26:07,840 So you send D3. 615 00:26:10,380 --> 00:26:15,640 And then you have a period of time, which is the RTO. 616 00:26:15,640 --> 00:26:18,050 No ACK happens. 617 00:26:18,050 --> 00:26:19,780 You send D3 again. 618 00:26:19,780 --> 00:26:22,160 And maybe no ACK happens for a while. 619 00:26:22,160 --> 00:26:23,630 You have another RTO. 620 00:26:23,630 --> 00:26:25,760 I'll assume that the RTO was fixed here. 621 00:26:25,760 --> 00:26:26,900 And you send D3 again. 622 00:26:29,460 --> 00:26:32,230 And you get an ACK here. 623 00:26:32,230 --> 00:26:35,550 And then you send D4 here, and so forth, right? 624 00:26:35,550 --> 00:26:39,690 That's an example of what could happen in a particular time 625 00:26:39,690 --> 00:26:42,360 evolution of the protocol. 626 00:26:42,360 --> 00:26:44,700 What I mean by throughput is that I 627 00:26:44,700 --> 00:26:47,160 would like to run such an experiment for a very 628 00:26:47,160 --> 00:26:49,495 long time, or run many, many such experiments, which 629 00:26:49,495 --> 00:26:51,870 is sort of equivalent to running an experiment for a very 630 00:26:51,870 --> 00:26:56,250 long time, and then count how many packets did I successfully 631 00:26:56,250 --> 00:26:57,522 get at the receiver. 632 00:26:57,522 --> 00:26:58,980 Or equivalently, I can ask how many 633 00:26:58,980 --> 00:27:02,410 ACKs did I get at the sender over that long experiment, 634 00:27:02,410 --> 00:27:03,000 right? 635 00:27:03,000 --> 00:27:06,030 And the number of ACKs that I get at the center divided 636 00:27:06,030 --> 00:27:09,930 by the time of that experiment will tell me the number 637 00:27:09,930 --> 00:27:11,310 of packets per second. 638 00:27:14,910 --> 00:27:17,830 Or put another way, if I run the experiment 639 00:27:17,830 --> 00:27:20,830 for some long period of time, and I 640 00:27:20,830 --> 00:27:23,310 receive n packets coming back-- 641 00:27:23,310 --> 00:27:25,990 right? 642 00:27:25,990 --> 00:27:29,032 If I receive n acknowledgments-- 643 00:27:33,660 --> 00:27:38,820 and if the expected time here between when 644 00:27:38,820 --> 00:27:41,215 I send a data packet-- 645 00:27:41,215 --> 00:27:42,090 I send a data packet. 646 00:27:42,090 --> 00:27:42,555 I get an ACK. 647 00:27:42,555 --> 00:27:43,370 I send a data packet. 648 00:27:43,370 --> 00:27:43,912 I get an ACK. 649 00:27:43,912 --> 00:27:45,720 I send a data packet, and I get an ACK. 650 00:27:45,720 --> 00:27:47,880 I send a data packet, and I get an ACK. 651 00:27:47,880 --> 00:27:50,710 If I take the expected value of that time-- 652 00:27:50,710 --> 00:27:53,070 that is, the expected time between when I send a packet 653 00:27:53,070 --> 00:27:55,830 and one I get an ACK-- 654 00:27:55,830 --> 00:28:04,470 the 1 over that number, 1 over the expected time, 655 00:28:04,470 --> 00:28:07,860 is equal to my throughput in packets per second. 656 00:28:12,240 --> 00:28:14,550 Because if I run the experiment for a long time, 657 00:28:14,550 --> 00:28:17,700 I'm going to get some number of acknowledgments. 658 00:28:17,700 --> 00:28:19,500 So if I run it for some period of time 659 00:28:19,500 --> 00:28:24,430 where n times e of t-- where e of t is number here, 660 00:28:24,430 --> 00:28:26,070 and I get back an acknowledgment, 661 00:28:26,070 --> 00:28:29,520 n divided by n times e of t is my throughput. 662 00:28:29,520 --> 00:28:32,010 And therefore, 1 over the expected time 663 00:28:32,010 --> 00:28:34,670 is the throughput of my experiment, right? 664 00:28:34,670 --> 00:28:37,170 So this should be intuitive, because what's really happening 665 00:28:37,170 --> 00:28:39,900 is, with a little bit of handwaving, 666 00:28:39,900 --> 00:28:42,923 actually, that I send data. 667 00:28:42,923 --> 00:28:43,465 I get an ACK. 668 00:28:43,465 --> 00:28:44,760 Send data, I get an ACK. 669 00:28:44,760 --> 00:28:46,690 There's a certain expected amount of time, 670 00:28:46,690 --> 00:28:50,345 so I will send 1 over that packets per second, OK? 671 00:28:50,345 --> 00:28:51,720 So in other words, the throughput 672 00:28:51,720 --> 00:28:53,280 is the reciprocal of the expected amount 673 00:28:53,280 --> 00:28:54,690 of time between when I send a packet 674 00:28:54,690 --> 00:28:56,065 and when I get an acknowledgment. 675 00:28:56,065 --> 00:28:58,320 So it's enough for us to compute the expected 676 00:28:58,320 --> 00:29:04,060 value of this time, right, or the mean value of that time. 677 00:29:04,060 --> 00:29:08,672 All right, so we could do that calculation in a simpler way. 678 00:29:08,672 --> 00:29:10,380 There's the sort of tedious way to do it, 679 00:29:10,380 --> 00:29:12,300 and there's a very simple, nice way to do it. 680 00:29:12,300 --> 00:29:22,830 So we want to calculate expected time between data and ACK. 681 00:29:22,830 --> 00:29:26,300 And one way to do this is to say that-- 682 00:29:26,300 --> 00:29:28,790 let's say I send a data packet. 683 00:29:28,790 --> 00:29:30,260 One of two things can happen. 684 00:29:30,260 --> 00:29:34,460 I either get an ACK for it, or I don't get an ACK for it. 685 00:29:34,460 --> 00:29:36,697 What's the probability that if I send a data packet, 686 00:29:36,697 --> 00:29:37,530 I get an ACK for it? 687 00:29:40,440 --> 00:29:47,200 Well, the probability that I send a packet 688 00:29:47,200 --> 00:29:49,765 and I don't get an ACK for it is L. Therefore, 689 00:29:49,765 --> 00:29:52,390 the probability that if I send a data packet, I get ACK for it, 690 00:29:52,390 --> 00:29:54,490 is 1 minus L, right? 691 00:29:54,490 --> 00:30:03,767 So with probability 1 minus L, I send a data packet, 692 00:30:03,767 --> 00:30:05,350 and I immediately get-- and when I say 693 00:30:05,350 --> 00:30:11,530 "immediately," I get an ACK for that data packet, right? 694 00:30:11,530 --> 00:30:12,760 And how long does that take? 695 00:30:12,760 --> 00:30:15,730 If I get an ACK for it, the ACK comes back to me 696 00:30:15,730 --> 00:30:19,600 in a time which is equal to RTT, the Round-Trip Time, right? 697 00:30:19,600 --> 00:30:22,030 So therefore, I can write a formula that looks like this. 698 00:30:22,030 --> 00:30:25,150 I can write this expected time which 699 00:30:25,150 --> 00:30:29,760 I'm trying to calculate as being equal to 1 minus L. 700 00:30:29,760 --> 00:30:32,470 With probability 1 minus L, the expected time between when 701 00:30:32,470 --> 00:30:34,650 I send a data packet and when I get an ACK 702 00:30:34,650 --> 00:30:42,700 for it is equal to the RTT, right? 703 00:30:42,700 --> 00:30:44,890 Because 1 minus L is, by definition, the probability 704 00:30:44,890 --> 00:30:46,765 that I send a packet and I get an ACK for it. 705 00:30:46,765 --> 00:30:48,820 Send a data packet and get an ACK. 706 00:30:48,820 --> 00:30:52,600 Now, what happens with probability L? 707 00:30:52,600 --> 00:30:54,550 With probability L, I send a data packet, 708 00:30:54,550 --> 00:30:57,070 and I don't get an ACK for it. 709 00:30:57,070 --> 00:31:00,040 So now I want to compute the expected time given 710 00:31:00,040 --> 00:31:02,493 that I don't get an ACK for it. 711 00:31:02,493 --> 00:31:03,910 The first thing that has to happen 712 00:31:03,910 --> 00:31:05,590 is I need to take a timeout. 713 00:31:05,590 --> 00:31:08,860 So I have to wait for a period of time shown in this picture 714 00:31:08,860 --> 00:31:11,350 given by the RTO. 715 00:31:11,350 --> 00:31:13,750 And then once I wait for that RTO, 716 00:31:13,750 --> 00:31:15,670 and I now start by sending a data 717 00:31:15,670 --> 00:31:18,100 packet, the expected amount of time 718 00:31:18,100 --> 00:31:20,320 before I get an ACK for that data packet 719 00:31:20,320 --> 00:31:22,630 is exactly equal to the original expected time 720 00:31:22,630 --> 00:31:24,170 that I'm trying to calculate, right? 721 00:31:24,170 --> 00:31:26,470 Because it doesn't matter what happened in the past. 722 00:31:26,470 --> 00:31:27,595 Let's say I take a timeout. 723 00:31:27,595 --> 00:31:30,190 And now, I come back here and [INAUDIBLE].. 724 00:31:30,190 --> 00:31:31,690 I'm not going to send a data packet. 725 00:31:31,690 --> 00:31:33,565 What's the expected time before I get an ACK? 726 00:31:33,565 --> 00:31:36,130 Well, that's exactly equal to the same answer 727 00:31:36,130 --> 00:31:39,110 that we're trying to calculate, this expected time over here. 728 00:31:39,110 --> 00:31:42,640 Therefore, I could write this recursion type of relationship. 729 00:31:42,640 --> 00:31:47,680 The expected time is 1 minus L the RTT plus L times the RTO 730 00:31:47,680 --> 00:31:53,740 plus the same expected time that I'm trying to calculate, right? 731 00:31:53,740 --> 00:31:55,570 What this says is with probably 1 minus L, 732 00:31:55,570 --> 00:31:59,890 the time it'll take for me to get an ACK is equal to the RTT. 733 00:31:59,890 --> 00:32:02,890 And with probability L, it's equal to-- first of all, 734 00:32:02,890 --> 00:32:03,520 this RTO-- 735 00:32:03,520 --> 00:32:06,070 I have to wait for that retransmission timeout. 736 00:32:06,070 --> 00:32:08,988 And then once I do that, well, I have to add some more time. 737 00:32:08,988 --> 00:32:10,780 And that time that I have to add is exactly 738 00:32:10,780 --> 00:32:14,710 equal to the same expected time from the left-hand side 739 00:32:14,710 --> 00:32:17,080 that I'm trying to calculate. 740 00:32:17,080 --> 00:32:18,680 Does this makes sense? 741 00:32:18,680 --> 00:32:20,680 You could kind of do this in a more tedious way. 742 00:32:20,680 --> 00:32:23,440 You could say, well, with probability 1 minus L, 743 00:32:23,440 --> 00:32:25,090 my time is RTT. 744 00:32:25,090 --> 00:32:28,090 With probability L times 1 minus L, 745 00:32:28,090 --> 00:32:31,470 the time is equal to RTT plus RTO. 746 00:32:31,470 --> 00:32:35,840 With probability L squared times 1 minus L, 747 00:32:35,840 --> 00:32:37,240 this is, like, two losses. 748 00:32:37,240 --> 00:32:38,800 And then a retransmission-- the time 749 00:32:38,800 --> 00:32:41,890 is 2 times the RTO plus RTT. 750 00:32:41,890 --> 00:32:43,858 With probability LQ times 1 minus L, it's that. 751 00:32:43,858 --> 00:32:46,150 If you do all of that stuff, you'll get the same thing. 752 00:32:49,150 --> 00:32:50,148 But this is the more-- 753 00:32:50,148 --> 00:32:51,440 there's a simpler way to do it. 754 00:32:51,440 --> 00:32:55,180 So if you run take the expected time over to one side 755 00:32:55,180 --> 00:32:59,680 and solve this equation, what you'll end up with 756 00:32:59,680 --> 00:33:03,760 is that the expected time is equal to RTT plus L over 1 757 00:33:03,760 --> 00:33:05,280 minus L times the RTO. 758 00:33:10,390 --> 00:33:13,262 I mean, as the packet loss rate becomes larger and larger 759 00:33:13,262 --> 00:33:15,538 and larger, this term starts to dominate 760 00:33:15,538 --> 00:33:17,830 because L over 1 minus L starts to be bigger and bigger 761 00:33:17,830 --> 00:33:21,580 and bigger, which is what you would expect. 762 00:33:21,580 --> 00:33:23,920 If the directional packet loss rate is large, 763 00:33:23,920 --> 00:33:26,450 you'd expect the RTO terms to start to dominate, 764 00:33:26,450 --> 00:33:29,500 and the expected time is larger and larger and larger. 765 00:33:29,500 --> 00:33:33,163 If the packet loss rate is zero, then the expected time 766 00:33:33,163 --> 00:33:34,330 is exactly equal to the RTT. 767 00:33:34,330 --> 00:33:34,900 You send a packet. 768 00:33:34,900 --> 00:33:35,365 You get an ACK. 769 00:33:35,365 --> 00:33:37,130 And with an RTT, you send the next packet. 770 00:33:37,130 --> 00:33:38,110 You get an ACK. 771 00:33:38,110 --> 00:33:41,440 And of course, the throughput's equal to 1 over the expected 772 00:33:41,440 --> 00:33:42,040 time. 773 00:33:42,040 --> 00:33:46,390 That's the reciprocal of the expected time, OK? 774 00:33:46,390 --> 00:33:47,853 Now, what's the best case here? 775 00:33:47,853 --> 00:33:49,270 The best case here is that you get 776 00:33:49,270 --> 00:33:51,310 one packet per round-trip time. 777 00:33:51,310 --> 00:33:53,500 The worst case is arbitrarily back depending 778 00:33:53,500 --> 00:33:55,750 on the packet loss rate. 779 00:33:55,750 --> 00:33:58,870 But the important point here is that even in the best case, 780 00:33:58,870 --> 00:34:00,760 you're able to send only one packet, at most, 781 00:34:00,760 --> 00:34:04,460 one packet per round-trip time. 782 00:34:04,460 --> 00:34:06,740 The question is, how good or bad is 783 00:34:06,740 --> 00:34:10,150 one packet per round-trip time? 784 00:34:10,150 --> 00:34:11,817 Is this clear, this intuition behind why 785 00:34:11,817 --> 00:34:13,900 this is one packet per round-trip time in the best 786 00:34:13,900 --> 00:34:14,427 case? 787 00:34:14,427 --> 00:34:15,969 That should be pretty obvious, right? 788 00:34:15,969 --> 00:34:16,570 I send a packet. 789 00:34:16,570 --> 00:34:17,139 I get an ACK. 790 00:34:17,139 --> 00:34:17,722 Send a packet. 791 00:34:17,722 --> 00:34:18,280 I get an ACK. 792 00:34:18,280 --> 00:34:20,980 This calculation just shows a little bit more detail 793 00:34:20,980 --> 00:34:24,590 about what happens when the packet loss rate's non-zero. 794 00:34:24,590 --> 00:34:26,860 So if the packet loss rate is, say, 20%, 795 00:34:26,860 --> 00:34:29,050 you take 1/5 over 4/5. 796 00:34:29,050 --> 00:34:33,949 So it's RTT plus 1/4 of the retransmission timeout. 797 00:34:33,949 --> 00:34:35,719 That's what it says the expected time is. 798 00:34:35,719 --> 00:34:39,230 And 1 over that is throughput. 799 00:34:39,230 --> 00:34:40,920 Now, how bad or good-- is it clear? 800 00:34:40,920 --> 00:34:42,037 Any questions? 801 00:34:45,020 --> 00:34:49,270 OK, so now, how good or bad is this 1 over the round trip 802 00:34:49,270 --> 00:34:49,770 time? 803 00:34:49,770 --> 00:34:57,020 So let's say that you have a network between Boston to-- 804 00:34:57,020 --> 00:34:59,870 I don't know-- San Francisco. 805 00:34:59,870 --> 00:35:02,037 And if you do these pings or whatever, let's-- 806 00:35:02,037 --> 00:35:03,620 I mean, I don't know the real numbers, 807 00:35:03,620 --> 00:35:05,810 but let's say it's 80 milliseconds. 808 00:35:05,810 --> 00:35:07,470 Just for the calculation to be easier, 809 00:35:07,470 --> 00:35:09,500 let's assume it's 100 milliseconds. 810 00:35:09,500 --> 00:35:14,780 And let's say that a packet on the internet it's 811 00:35:14,780 --> 00:35:17,122 about 10,000 bits. 812 00:35:17,122 --> 00:35:18,080 So let's make it bytes. 813 00:35:18,080 --> 00:35:26,073 Let's say that it's 1,000, say, 1,500 bytes. 814 00:35:26,073 --> 00:35:27,740 So what this says is that the throughput 815 00:35:27,740 --> 00:35:29,510 that I would get with the stop-and-wait protocol 816 00:35:29,510 --> 00:35:30,890 if I ran it on this internet path 817 00:35:30,890 --> 00:35:36,990 would be 1,500 bytes divided by 100 milliseconds. 818 00:35:36,990 --> 00:35:45,080 So that's 15,000 bytes per second, 15 kilobytes a second, 819 00:35:45,080 --> 00:35:47,240 which might have been really, really good in 1985, 820 00:35:47,240 --> 00:35:49,230 but no one's going to be happy with this today. 821 00:35:52,150 --> 00:35:54,190 I mean, you might have a link that's a megabyte 822 00:35:54,190 --> 00:35:56,590 a second or a gigabyte a second or 10-- you know, 823 00:35:56,590 --> 00:35:57,610 bigger than that. 824 00:35:57,610 --> 00:36:01,570 But no matter how fast the network links are, 825 00:36:01,570 --> 00:36:03,250 this protocol is completely dominated 826 00:36:03,250 --> 00:36:06,010 by the delay or the latency, the round-trip latency, 827 00:36:06,010 --> 00:36:07,690 between the sender and the receiver. 828 00:36:07,690 --> 00:36:11,880 And you end up with a throughput that's pegged to a small value. 829 00:36:11,880 --> 00:36:14,317 And so, people don't like that. 830 00:36:14,317 --> 00:36:15,900 So question is, how can you do better? 831 00:36:15,900 --> 00:36:18,090 What can you do now to this protocol? 832 00:36:18,090 --> 00:36:20,820 Or come up with a new method, a new protocol 833 00:36:20,820 --> 00:36:25,610 that would improve the throughput of this system. 834 00:36:25,610 --> 00:36:27,860 Because if people pay money for network links, 835 00:36:27,860 --> 00:36:30,525 they'd like to actually get higher performance from it. 836 00:36:30,525 --> 00:36:31,400 So what could you do? 837 00:36:35,256 --> 00:36:36,347 AUDIENCE: Larger packets? 838 00:36:36,347 --> 00:36:37,347 HARI BALAKRISHNAN: What? 839 00:36:37,347 --> 00:36:38,600 AUDIENCE: Larger packets? 840 00:36:38,600 --> 00:36:40,017 HARI BALAKRISHNAN: Larger packets. 841 00:36:40,017 --> 00:36:43,562 Well, yeah, larger packets is-- 842 00:36:43,562 --> 00:36:45,020 yeah, why don't we make our packets 843 00:36:45,020 --> 00:36:48,210 as big as the five we want to send? 844 00:36:48,210 --> 00:36:49,118 Actually, I digress. 845 00:36:49,118 --> 00:36:50,660 Why don't we make packets really big? 846 00:36:50,660 --> 00:36:53,122 Like, I got a megabyte file or a gigabyte file to send. 847 00:36:53,122 --> 00:36:55,205 Why do I have to break it up into smaller packets? 848 00:36:59,436 --> 00:37:01,410 AUDIENCE: Larger packets use more bandwidth? 849 00:37:01,410 --> 00:37:03,160 HARI BALAKRISHNAN: Well, to send the data, 850 00:37:03,160 --> 00:37:04,870 no matter if we break it up small or big, 851 00:37:04,870 --> 00:37:07,411 you're going to use the same bandwidth. 852 00:37:07,411 --> 00:37:08,740 I mean, that's a good question. 853 00:37:08,740 --> 00:37:09,782 Yeah, you have an answer? 854 00:37:09,782 --> 00:37:12,955 AUDIENCE: [INAUDIBLE] how to [INAUDIBLE] over time. 855 00:37:12,955 --> 00:37:14,580 HARI BALAKRISHNAN: That's kind of true. 856 00:37:14,580 --> 00:37:17,212 You know, if a packet is, you know, 857 00:37:17,212 --> 00:37:19,170 let's say a gigabyte file you want to transmit. 858 00:37:19,170 --> 00:37:20,670 And you send that in one atomic unit, 859 00:37:20,670 --> 00:37:22,420 and goes through four hops in the network, 860 00:37:22,420 --> 00:37:24,210 and then it gets dropped on the first hop, 861 00:37:24,210 --> 00:37:26,293 you end up having to send an entire gigabyte again 862 00:37:26,293 --> 00:37:27,630 over all those other hops. 863 00:37:27,630 --> 00:37:29,160 That's actually not good. 864 00:37:29,160 --> 00:37:30,930 But in fact, really large packets 865 00:37:30,930 --> 00:37:33,600 are probably a bad idea even for networks 866 00:37:33,600 --> 00:37:35,517 which don't drop any packets. 867 00:37:35,517 --> 00:37:38,100 I mean, think of the case when I have a gigabyte file to send, 868 00:37:38,100 --> 00:37:40,440 and you have a gigabyte file to send. 869 00:37:40,440 --> 00:37:42,870 The problem if you make these packets really big 870 00:37:42,870 --> 00:37:45,977 is that one of us is-- on a shared link, only one of us 871 00:37:45,977 --> 00:37:48,310 can send that packet, which means the other guy is going 872 00:37:48,310 --> 00:37:50,340 to be waiting a really, really long time for him 873 00:37:50,340 --> 00:37:51,970 to send that packet. 874 00:37:51,970 --> 00:37:55,500 So the reason why, in the end, packets are modest size 875 00:37:55,500 --> 00:37:58,740 has to do with our wanting to share the network evenly 876 00:37:58,740 --> 00:38:00,500 over smaller time scales. 877 00:38:00,500 --> 00:38:03,260 It's because we want to give fairness across smaller time 878 00:38:03,260 --> 00:38:05,723 scales, allowing everybody who's competing 879 00:38:05,723 --> 00:38:06,640 access to the network. 880 00:38:06,640 --> 00:38:08,598 So even if we have big amounts of data to send, 881 00:38:08,598 --> 00:38:11,280 we prefer to break them up into smaller chunks 882 00:38:11,280 --> 00:38:13,860 among other reasons, one reason being 883 00:38:13,860 --> 00:38:18,020 we don't want to start other connections 884 00:38:18,020 --> 00:38:20,430 and prevent them from gaining access to the network 885 00:38:20,430 --> 00:38:24,140 because there's some huge transfer sitting in front. 886 00:38:24,140 --> 00:38:27,380 So that's part of the reason. 887 00:38:27,380 --> 00:38:29,777 So anyway, so bigger packets doesn't quite cut it. 888 00:38:29,777 --> 00:38:30,860 So what else could you do? 889 00:38:30,860 --> 00:38:31,614 Yes? 890 00:38:31,614 --> 00:38:35,002 AUDIENCE: [INAUDIBLE] to send. 891 00:38:35,002 --> 00:38:39,358 So if you cannot [INAUDIBLE]. 892 00:38:43,128 --> 00:38:44,920 HARI BALAKRISHNAN: OK, you know, well, I'll 893 00:38:44,920 --> 00:38:46,600 come back to this on Monday. 894 00:38:46,600 --> 00:38:48,490 That's actually a really good idea. 895 00:38:48,490 --> 00:38:50,608 But when would you stop for 8, 16, 32? 896 00:38:50,608 --> 00:38:52,150 I mean, at some point, this is like-- 897 00:38:52,150 --> 00:38:54,610 AUDIENCE: [INAUDIBLE] at some point, it's going to tail. 898 00:38:54,610 --> 00:38:55,630 HARI BALAKRISHNAN: Because packets are lost. 899 00:38:55,630 --> 00:38:57,100 AUDIENCE: Yeah, so you go back. 900 00:38:57,100 --> 00:38:59,183 HARI BALAKRISHNAN: OK, this is a really good idea. 901 00:38:59,183 --> 00:39:02,260 We're not actually going to teach that here in this course. 902 00:39:02,260 --> 00:39:04,240 This is actually what TCP does in the beginning 903 00:39:04,240 --> 00:39:05,710 of the connection. 904 00:39:05,710 --> 00:39:10,850 But before we-- what else could you do? 905 00:39:10,850 --> 00:39:12,210 That's a good idea. 906 00:39:12,210 --> 00:39:13,362 Yeah. 907 00:39:13,362 --> 00:39:15,310 AUDIENCE: You could send a fixed number. 908 00:39:15,310 --> 00:39:16,810 HARI BALAKRISHNAN: Yeah, you could do a fixed number. 909 00:39:16,810 --> 00:39:18,102 You know, somebody could pick-- 910 00:39:18,102 --> 00:39:19,660 I actually kind of-- 911 00:39:19,660 --> 00:39:22,960 it is a really good idea to do 1, 2, 4, 8. 912 00:39:22,960 --> 00:39:26,590 And then if it fails, you come back down to, say, 1 or 1/2 913 00:39:26,590 --> 00:39:29,690 of whatever worked the last time and then continue from that. 914 00:39:29,690 --> 00:39:31,690 That particular thing has a name to it. 915 00:39:31,690 --> 00:39:33,460 That protocol is called slow start. 916 00:39:33,460 --> 00:39:35,400 It's ironic because it's really fast. 917 00:39:35,400 --> 00:39:37,490 It's exponential, right-- 1, 2, 4, 8. 918 00:39:37,490 --> 00:39:40,690 But yet, it's called slow start. 919 00:39:40,690 --> 00:39:43,870 I'll probably tell you more about it on Wednesday. 920 00:39:43,870 --> 00:39:46,270 But we'll ease into that solution. 921 00:39:46,270 --> 00:39:47,980 We'll do something simpler. 922 00:39:47,980 --> 00:39:50,230 We'll use something called a sliding window protocol 923 00:39:50,230 --> 00:39:51,272 with a fixed-size window. 924 00:39:51,272 --> 00:39:55,150 You just make that 1 be 7 or 4 or 6 or 8. 925 00:39:55,150 --> 00:39:59,440 I'll tell you later next time how you pick that value, OK? 926 00:39:59,440 --> 00:40:01,690 And one way to pick that value is to do it dynamically 927 00:40:01,690 --> 00:40:03,750 like the gentleman in the front said. 928 00:40:03,750 --> 00:40:05,540 It's more complicated. 929 00:40:05,540 --> 00:40:08,210 But let's just pick a fixed-size value. 930 00:40:08,210 --> 00:40:10,155 So the idea is actually very, very simple. 931 00:40:10,155 --> 00:40:11,970 Now that I have one packet outstanding. 932 00:40:11,970 --> 00:40:13,780 We use this idea in computer science. 933 00:40:13,780 --> 00:40:15,190 We use this over and over again-- 934 00:40:15,190 --> 00:40:16,270 pipelining. 935 00:40:16,270 --> 00:40:18,310 So you just send multiple of them 936 00:40:18,310 --> 00:40:20,560 and have multiple outstanding packets. 937 00:40:20,560 --> 00:40:23,230 By "outstanding," I mean a packet that hasn't yet 938 00:40:23,230 --> 00:40:24,002 been acknowledged. 939 00:40:24,002 --> 00:40:25,960 A data packet that hasn't yet been acknowledged 940 00:40:25,960 --> 00:40:28,300 is called an outstanding data packet. 941 00:40:28,300 --> 00:40:30,550 And you have multiple of these outstanding. 942 00:40:30,550 --> 00:40:32,950 And every time you get an acknowledgment, 943 00:40:32,950 --> 00:40:35,425 you send one more packet. 944 00:40:35,425 --> 00:40:37,300 So that's shown in this timeline here, right? 945 00:40:37,300 --> 00:40:38,560 So you start here. 946 00:40:38,560 --> 00:40:39,310 You send a packet. 947 00:40:44,130 --> 00:40:45,750 I don't know why this isn't working. 948 00:40:45,750 --> 00:40:46,920 Ah, there we go. 949 00:40:46,920 --> 00:40:47,670 You send a packet. 950 00:40:47,670 --> 00:40:48,753 You get an acknowledgment. 951 00:40:48,753 --> 00:40:51,103 When you get an acknowledgment, you send another packet. 952 00:40:51,103 --> 00:40:52,020 Get an acknowledgment. 953 00:40:52,020 --> 00:40:52,860 You send another packet. 954 00:40:52,860 --> 00:40:54,870 But in the meantime, there are these other acknowledgments 955 00:40:54,870 --> 00:40:55,663 coming in. 956 00:40:55,663 --> 00:40:57,330 And the rule is very simple-- every time 957 00:40:57,330 --> 00:41:00,960 you get an acknowledgment that you have not seen before, send 958 00:41:00,960 --> 00:41:02,880 the next packet in sequence. 959 00:41:02,880 --> 00:41:05,520 So the sender just keeps sending packets in sequence order. 960 00:41:05,520 --> 00:41:07,020 Every time it gets an acknowledgment 961 00:41:07,020 --> 00:41:10,260 that it hasn't seen before for a packet 962 00:41:10,260 --> 00:41:13,680 that it had sent before, it sends the next incrementing 963 00:41:13,680 --> 00:41:16,410 sequence number. 964 00:41:16,410 --> 00:41:18,530 So this painstaking animation will 965 00:41:18,530 --> 00:41:21,920 attempt to show you that, assuming it's correct. 966 00:41:21,920 --> 00:41:24,860 So the window here is five packets, OK? 967 00:41:24,860 --> 00:41:27,260 I'll tell you later some guidelines on how 968 00:41:27,260 --> 00:41:28,940 to pick this window size. 969 00:41:28,940 --> 00:41:30,590 But this number of packets here is 970 00:41:30,590 --> 00:41:33,933 called the window, the number of outstanding packets, 971 00:41:33,933 --> 00:41:35,600 or the number of unacknowledged packets. 972 00:41:35,600 --> 00:41:37,832 It's always going to be 5. 973 00:41:37,832 --> 00:41:39,290 It's going to be 5 in this example. 974 00:41:39,290 --> 00:41:42,560 It's always going to be a fixed value in our protocol, OK? 975 00:41:42,560 --> 00:41:45,200 So you send the first packet. 976 00:41:45,200 --> 00:41:47,710 When you get an acknowledgment for that first packet, 977 00:41:47,710 --> 00:41:51,783 you slide the window forward by 1, and you send packet 6. 978 00:41:51,783 --> 00:41:53,700 When you get an acknowledgment for a packet 2, 979 00:41:53,700 --> 00:41:57,528 you slide the window forward, and you send packet 7. 980 00:41:57,528 --> 00:41:59,070 When you get an acknowledgment for 3, 981 00:41:59,070 --> 00:42:05,050 you slide the window forward, and you send packet 8. 982 00:42:05,050 --> 00:42:06,270 This is-- sorry? 983 00:42:06,270 --> 00:42:06,770 Yeah. 984 00:42:06,770 --> 00:42:11,040 AUDIENCE: So it appears [INAUDIBLE] out of order. 985 00:42:11,040 --> 00:42:12,790 HARI BALAKRISHNAN: That's a good question. 986 00:42:12,790 --> 00:42:14,570 I'll get to that in a moment. 987 00:42:14,570 --> 00:42:17,430 The answer is that the sender's rule is always the same. 988 00:42:17,430 --> 00:42:19,180 Yes, you get acknowledgments out of order. 989 00:42:19,180 --> 00:42:21,640 As long as it's an acknowledgment for a packet-- 990 00:42:21,640 --> 00:42:23,560 sorry, as long as it's an acknowledgment 991 00:42:23,560 --> 00:42:26,320 that you have not seen before for a packet 992 00:42:26,320 --> 00:42:30,220 that you have actually sent, you slide the window forward by 1 993 00:42:30,220 --> 00:42:32,440 and send a new packet, OK? 994 00:42:32,440 --> 00:42:35,463 And you keep track of the fact that you received 995 00:42:35,463 --> 00:42:37,630 an acknowledgment, so you know that you should never 996 00:42:37,630 --> 00:42:38,588 retransmit that packet. 997 00:42:41,318 --> 00:42:43,110 I want to define this thing and pause here. 998 00:42:43,110 --> 00:42:45,840 I want you to understand the definition of a window 999 00:42:45,840 --> 00:42:47,580 and internalize it. 1000 00:42:47,580 --> 00:42:50,400 If the window size is W, what it means 1001 00:42:50,400 --> 00:42:53,310 is that the maximum number of unacknowledged packets that you 1002 00:42:53,310 --> 00:42:57,420 can have in the connection is W. There are many different ways 1003 00:42:57,420 --> 00:42:59,220 of defining a window. 1004 00:42:59,220 --> 00:43:01,860 In fact, TCP inside it has two windows. 1005 00:43:01,860 --> 00:43:03,940 This definition is one of those windows. 1006 00:43:03,940 --> 00:43:06,590 I won't talk about the second definition here. 1007 00:43:06,590 --> 00:43:08,290 I'll get to it next week. 1008 00:43:08,290 --> 00:43:11,140 It's not important for us right now. 1009 00:43:11,140 --> 00:43:13,200 So again, to repeat, if the window size is W, 1010 00:43:13,200 --> 00:43:16,350 it means that the maximum number of unacknowledged packets 1011 00:43:16,350 --> 00:43:20,550 in the system in the protocol is W. So the rule of the sender 1012 00:43:20,550 --> 00:43:22,590 is going to be to very religiously adhere 1013 00:43:22,590 --> 00:43:24,000 to this rule. 1014 00:43:24,000 --> 00:43:26,440 In other words, every time it gets an acknowledgment, 1015 00:43:26,440 --> 00:43:28,440 it waits and sees whether it's an acknowledgment 1016 00:43:28,440 --> 00:43:32,100 for a packet it has sent before that it has not seen before. 1017 00:43:32,100 --> 00:43:33,790 If you get an acknowledgment like that, 1018 00:43:33,790 --> 00:43:37,320 it means that some packet has been received, 1019 00:43:37,320 --> 00:43:39,810 which means you can get rid of that packet from the stack 1020 00:43:39,810 --> 00:43:43,835 of unacknowledged packets that you have and send a new packet. 1021 00:43:43,835 --> 00:43:45,210 Because you can send a new packet 1022 00:43:45,210 --> 00:43:49,330 because you know that the number of unacknowledged packets 1023 00:43:49,330 --> 00:43:52,560 reduced by 1 because you got an ACK, which means 1024 00:43:52,560 --> 00:43:54,312 you can now send a new packet, OK? 1025 00:43:54,312 --> 00:43:55,770 It's a very simple rule if you just 1026 00:43:55,770 --> 00:43:57,690 follow that idea to implement. 1027 00:43:57,690 --> 00:43:59,962 It also is surprisingly easy to get wrong. 1028 00:43:59,962 --> 00:44:00,462 Yeah. 1029 00:44:00,462 --> 00:44:03,378 AUDIENCE: So the window doesn't necessarily 1030 00:44:03,378 --> 00:44:05,258 have to be consecutive? 1031 00:44:05,258 --> 00:44:07,800 HARI BALAKRISHNAN: The window doesn't have to be consecutive. 1032 00:44:07,800 --> 00:44:09,450 This is a really, really good point. 1033 00:44:09,450 --> 00:44:10,710 And it's very tempting to implement 1034 00:44:10,710 --> 00:44:11,877 a window that's consecutive. 1035 00:44:11,877 --> 00:44:15,300 And you'll find that after a while, if you follow that idea, 1036 00:44:15,300 --> 00:44:17,545 and you do it wrongly, the protocol will just stall. 1037 00:44:17,545 --> 00:44:19,170 And every time, there's about a quarter 1038 00:44:19,170 --> 00:44:20,690 of the students, the first time they implemented this, 1039 00:44:20,690 --> 00:44:22,480 it just stops working after a while 1040 00:44:22,480 --> 00:44:23,730 as the packet loss rates grow. 1041 00:44:23,730 --> 00:44:25,320 So it's important that in this definition 1042 00:44:25,320 --> 00:44:27,300 of the protocol in the way it's defined here, 1043 00:44:27,300 --> 00:44:29,370 the window of unacknowledged packets-- 1044 00:44:29,370 --> 00:44:31,260 it's not necessarily consecutive. 1045 00:44:31,260 --> 00:44:36,270 So you could have packets 1, 2, 3, 4, 8, 9, 10, 11 outstanding 1046 00:44:36,270 --> 00:44:37,980 if your window size is 8. 1047 00:44:37,980 --> 00:44:40,230 The other guys may have gotten acknowledged. 1048 00:44:40,230 --> 00:44:44,150 That's absolutely true, yes. 1049 00:44:44,150 --> 00:44:45,290 OK? 1050 00:44:45,290 --> 00:44:47,190 All right, now what happens under all 1051 00:44:47,190 --> 00:44:49,600 these other weird cases that are going to happen here? 1052 00:44:49,600 --> 00:44:51,990 So let me first show you a timeline 1053 00:44:51,990 --> 00:44:55,480 of how a timeout is dealt with. 1054 00:44:55,480 --> 00:44:58,440 So let's say in this case, the window size is 1055 00:44:58,440 --> 00:45:00,640 5 again like it was before. 1056 00:45:00,640 --> 00:45:03,000 So everything is going wonderfully well here. 1057 00:45:03,000 --> 00:45:04,830 And let's say now you move on. 1058 00:45:04,830 --> 00:45:06,330 You send packets 6, 7, 8. 1059 00:45:06,330 --> 00:45:08,370 And let's say packet 8 is lost. 1060 00:45:08,370 --> 00:45:11,190 What the sender is going to do is it's going to send packet 9. 1061 00:45:11,190 --> 00:45:15,990 It's going to send packet 10 based on acknowledgments for 4 1062 00:45:15,990 --> 00:45:18,350 and 3 that it received before. 1063 00:45:18,350 --> 00:45:20,430 So, sorry, when it got acknowledgment 3, 1064 00:45:20,430 --> 00:45:21,405 it sent packet 8. 1065 00:45:21,405 --> 00:45:22,200 8 was lost. 1066 00:45:22,200 --> 00:45:24,060 The sender didn't know that at this point. 1067 00:45:24,060 --> 00:45:26,340 When it got an acknowledgment for 4, it sends 9. 1068 00:45:26,340 --> 00:45:28,848 When it got an acknowledgment for 5, it sends 10. 1069 00:45:28,848 --> 00:45:30,390 When it gets an acknowledgment for 6, 1070 00:45:30,390 --> 00:45:32,070 it goes ahead and sends 11. 1071 00:45:32,070 --> 00:45:35,790 When it gets an acknowledgment for 7, 1072 00:45:35,790 --> 00:45:37,830 it goes ahead and sends 12. 1073 00:45:37,830 --> 00:45:40,200 So at this point, the sender actually 1074 00:45:40,200 --> 00:45:45,600 has outstanding 12, 11, 10, 9, 8, OK? 1075 00:45:45,600 --> 00:45:49,200 Now, at some point, it discovers that-- 1076 00:45:49,200 --> 00:45:51,300 in fact, this picture continues. 1077 00:45:51,300 --> 00:45:53,550 In this picture, what happened is that you sent out 9. 1078 00:45:53,550 --> 00:45:55,050 You've got an acknowledgment for 9. 1079 00:45:55,050 --> 00:45:57,068 And at that point, you send out 13 1080 00:45:57,068 --> 00:45:58,860 because whenever you get an acknowledgment, 1081 00:45:58,860 --> 00:46:00,717 you send out the next consecutive packet 1082 00:46:00,717 --> 00:46:01,800 you should be sending out. 1083 00:46:01,800 --> 00:46:03,540 So at this point in time, the sender 1084 00:46:03,540 --> 00:46:05,340 has a bunch of outstanding packets in it, 1085 00:46:05,340 --> 00:46:06,507 and it's got acknowledgment. 1086 00:46:06,507 --> 00:46:09,710 And this is an interesting case because packet 8 was lost. 1087 00:46:09,710 --> 00:46:12,240 9 was sent later, and 9 got acknowledged. 1088 00:46:12,240 --> 00:46:14,368 But we still haven't timed out on 8. 1089 00:46:14,368 --> 00:46:16,410 So at this point in time, the outstanding packets 1090 00:46:16,410 --> 00:46:21,180 in the window are 13, 12, 11, 10, and 8, 1091 00:46:21,180 --> 00:46:24,750 giving you that nonconsecutive observation that you notice. 1092 00:46:24,750 --> 00:46:27,300 And then at some point in time, based on the round-trip time, 1093 00:46:27,300 --> 00:46:29,850 based on the black box, the guy timed out, 1094 00:46:29,850 --> 00:46:31,410 and 8 got retransmitted. 1095 00:46:31,410 --> 00:46:32,690 And then 8 got retransmitted. 1096 00:46:32,690 --> 00:46:35,065 You got an acknowledgment for 8, and the protocol sort of 1097 00:46:35,065 --> 00:46:38,020 continues in that fashion. 1098 00:46:38,020 --> 00:46:39,085 Does this makes sense? 1099 00:46:39,085 --> 00:46:42,940 So it's actually not that hard when you think about it. 1100 00:46:42,940 --> 00:46:46,830 What the sender does is a very simple idea, which 1101 00:46:46,830 --> 00:46:49,440 is every time it gets a new acknowledgment for a packet it 1102 00:46:49,440 --> 00:46:51,982 had sent before but hadn't seen an acknowledgment for before, 1103 00:46:51,982 --> 00:46:54,188 it just goes ahead and sends the next packet. 1104 00:46:54,188 --> 00:46:55,980 And then it has a separate process by which 1105 00:46:55,980 --> 00:46:57,420 it maintains this timeout. 1106 00:46:57,420 --> 00:46:59,047 And whenever an acknowledgment does not 1107 00:46:59,047 --> 00:47:00,630 arrive within a timeout, it goes ahead 1108 00:47:00,630 --> 00:47:02,640 and retransmits that back. 1109 00:47:02,640 --> 00:47:04,860 Now, when it retransmits the packet, 1110 00:47:04,860 --> 00:47:07,170 the assumption here is that the original packet 1111 00:47:07,170 --> 00:47:08,530 was actually lost. 1112 00:47:08,530 --> 00:47:12,793 So the timeout has to be bigger than-- 1113 00:47:12,793 --> 00:47:14,460 for the system to work well, the timeout 1114 00:47:14,460 --> 00:47:17,190 has to be bigger than the maximum time 1115 00:47:17,190 --> 00:47:20,110 that a packet can sit around in the system. 1116 00:47:20,110 --> 00:47:23,580 So if the timeout is too small, and you retransmit 8 too early, 1117 00:47:23,580 --> 00:47:25,530 it could be that 8 is not lost, but 8 is just 1118 00:47:25,530 --> 00:47:27,810 being reordered in the network and going on some very long 1119 00:47:27,810 --> 00:47:28,435 circulous path. 1120 00:47:28,435 --> 00:47:30,660 You know, I recently read that someone got a letter 1121 00:47:30,660 --> 00:47:32,140 in New York 70 years-- 1122 00:47:32,140 --> 00:47:35,260 it was sent in 1943, and it showed up, like, two weeks ago. 1123 00:47:35,260 --> 00:47:37,260 So, I mean, it could happen on the internet too. 1124 00:47:37,260 --> 00:47:39,510 I mean, quite literally, if you're on an Amtrak train, 1125 00:47:39,510 --> 00:47:41,400 and you're using their wireless network, 1126 00:47:41,400 --> 00:47:45,820 some packets come to you in 300 or 400 milliseconds, 1127 00:47:45,820 --> 00:47:47,190 which is arguably very long. 1128 00:47:47,190 --> 00:47:48,732 But literally, there are packets that 1129 00:47:48,732 --> 00:47:50,950 will come back to you a minute after you sent them-- 1130 00:47:50,950 --> 00:47:52,950 reach the receiver a minute after you sent them. 1131 00:47:52,950 --> 00:47:54,160 And they could be out of order. 1132 00:47:54,160 --> 00:47:55,993 So in fact, this is my student's, and I call 1133 00:47:55,993 --> 00:47:57,270 this the great Amtrak network. 1134 00:47:57,270 --> 00:47:58,980 It's really good because it gives us 1135 00:47:58,980 --> 00:48:01,650 really interesting research for others to work on. 1136 00:48:01,650 --> 00:48:03,150 But the people who are on that train 1137 00:48:03,150 --> 00:48:05,220 probably-- it's miserable. 1138 00:48:05,220 --> 00:48:07,030 So anyway, this could happen. 1139 00:48:07,030 --> 00:48:08,930 But, and so, the timeout is a heuristic. 1140 00:48:08,930 --> 00:48:11,850 It could be that 8 was retransmitted wrongly 1141 00:48:11,850 --> 00:48:13,260 in a spurious way. 1142 00:48:13,260 --> 00:48:15,940 But our hope is that if the timeout is long enough, 1143 00:48:15,940 --> 00:48:17,287 it could be that-- 1144 00:48:17,287 --> 00:48:18,870 if the timeout's long enough, the idea 1145 00:48:18,870 --> 00:48:21,855 is that you retransmit 8 because the original 8 was lost. 1146 00:48:21,855 --> 00:48:23,730 And now the outstanding packets in the window 1147 00:48:23,730 --> 00:48:27,300 are 8, 13, 12, 11, and 10. 1148 00:48:27,300 --> 00:48:32,220 But the 8 here is not that 8, but this 8. 1149 00:48:32,220 --> 00:48:35,580 But as long as the contents of 8 are the same, 1150 00:48:35,580 --> 00:48:37,268 it doesn't matter which 8 it is. 1151 00:48:37,268 --> 00:48:39,810 But of course, if the timeout is too small, there are two 8's 1152 00:48:39,810 --> 00:48:41,040 sitting in the network. 1153 00:48:41,040 --> 00:48:44,887 And now you actually have more than W packets in the window. 1154 00:48:44,887 --> 00:48:46,470 But as far as the sender is concerned, 1155 00:48:46,470 --> 00:48:49,347 it has exactly those 8, 10, 11, 12, and 13. 1156 00:48:49,347 --> 00:48:51,930 It's true that there's one more packet if the timeout happened 1157 00:48:51,930 --> 00:48:52,462 too early. 1158 00:48:52,462 --> 00:48:53,670 That's the network's problem. 1159 00:48:53,670 --> 00:48:55,087 As far as the sender is concerned, 1160 00:48:55,087 --> 00:48:57,690 it has five outstanding packets. 1161 00:48:57,690 --> 00:49:00,135 The receiver is a little trickier than in the other case 1162 00:49:00,135 --> 00:49:01,260 because what it has to do-- 1163 00:49:01,260 --> 00:49:03,260 I mean, it's trickier in that it has to maintain 1164 00:49:03,260 --> 00:49:04,990 a buffer of packets. 1165 00:49:04,990 --> 00:49:07,680 So the receiver has a little more of a job to do. 1166 00:49:07,680 --> 00:49:10,900 In the previous stop-and-wait protocol, 1167 00:49:10,900 --> 00:49:12,720 any time it got an out-of-order packet, 1168 00:49:12,720 --> 00:49:15,750 it's probably because the sender is badly implemented, right? 1169 00:49:15,750 --> 00:49:18,150 If the last sequence number I deliver to the application 1170 00:49:18,150 --> 00:49:21,353 was 17, and I got a 19, it's a bug. 1171 00:49:21,353 --> 00:49:22,770 Whereas here, is the last sequence 1172 00:49:22,770 --> 00:49:24,870 number I delivered to the application is 17, 1173 00:49:24,870 --> 00:49:27,535 and I get a 19, it means that, well, there's a window. 1174 00:49:27,535 --> 00:49:29,910 And maybe 18 was lost, or who knows what happened, right? 1175 00:49:29,910 --> 00:49:31,810 Maybe 18 will show up later. 1176 00:49:31,810 --> 00:49:33,743 So the receiver now has an interesting job. 1177 00:49:33,743 --> 00:49:35,160 And this is important because when 1178 00:49:35,160 --> 00:49:37,452 you implement this stuff in this protocol [INAUDIBLE],, 1179 00:49:37,452 --> 00:49:39,963 you've got to make sure that whenever you deliver packets 1180 00:49:39,963 --> 00:49:41,880 from the receiver protocol to the application, 1181 00:49:41,880 --> 00:49:45,290 you deliver it in order and update the last sequence 1182 00:49:45,290 --> 00:49:47,150 number you delivered, OK? 1183 00:49:47,150 --> 00:49:49,185 So that's important to do. 1184 00:49:49,185 --> 00:49:50,810 But if you do that and then acknowledge 1185 00:49:50,810 --> 00:49:52,820 a packet when it's received, just 1186 00:49:52,820 --> 00:49:54,110 send an acknowledgment for it. 1187 00:49:54,110 --> 00:49:56,395 The protocol will continue, and it will work well. 1188 00:49:56,395 --> 00:49:57,770 So this is what you'll be looking 1189 00:49:57,770 --> 00:50:00,020 at in the lab, the piece that's going to go out today. 1190 00:50:00,020 --> 00:50:01,190 This is the last lab. 1191 00:50:01,190 --> 00:50:03,420 And then on tomorrow in recitation, 1192 00:50:03,420 --> 00:50:05,263 we'll look at how the timeout is selected. 1193 00:50:05,263 --> 00:50:06,680 And then on Monday, I'll talk more 1194 00:50:06,680 --> 00:50:09,550 about an analysis of this protocol.