1 00:00:14,350 --> 00:00:17,520 So today we're going to continue our discussion of networking. 2 00:00:17,520 --> 00:00:19,570 If you remember from the last few times, 3 00:00:19,570 --> 00:00:25,300 we talked about these two different layers of the network 4 00:00:25,300 --> 00:00:26,000 stack so far. 5 00:00:26,000 --> 00:00:27,750 We talked about the link layer, and we 6 00:00:27,750 --> 00:00:29,250 talked about the network layer. 7 00:00:29,250 --> 00:00:32,580 And today were going to talk about the end to end layer. 8 00:00:32,580 --> 00:00:34,440 So what we've talked about so far 9 00:00:34,440 --> 00:00:38,270 has been a network stack that provides 10 00:00:38,270 --> 00:00:40,870 this abstraction of being able to send a message from one 11 00:00:40,870 --> 00:00:43,940 machine to another machine across a number of links 12 00:00:43,940 --> 00:00:45,509 in the network. 13 00:00:45,509 --> 00:00:47,050 And this network stack that we talked 14 00:00:47,050 --> 00:00:50,530 about is, if you will remember, a best effort network. 15 00:00:58,130 --> 00:01:01,390 So a best effort network, as you'll remember, 16 00:01:01,390 --> 00:01:05,370 is a network that is subject to losses. 17 00:01:05,370 --> 00:01:09,090 So some messages may not be properly transmitted 18 00:01:09,090 --> 00:01:11,110 from one point to the other point. 19 00:01:11,110 --> 00:01:15,560 It's subject to the possibility of reordering of messages, 20 00:01:15,560 --> 00:01:17,920 as messages may take, for example, 21 00:01:17,920 --> 00:01:20,850 different routes through the network. 22 00:01:20,850 --> 00:01:31,550 And it's subject to delays and congestion 23 00:01:31,550 --> 00:01:34,390 typically due to queuing within the network. 24 00:01:34,390 --> 00:01:38,355 So, today what we're going to talk about it and end layer. 25 00:01:38,355 --> 00:01:39,730 And the end to end layer is going 26 00:01:39,730 --> 00:01:42,350 to be the way that we're going to get that finally addressing 27 00:01:42,350 --> 00:01:44,433 some of these best effort network properties we've 28 00:01:44,433 --> 00:01:47,360 been kind of skirting around for the last few lectures. 29 00:01:47,360 --> 00:01:51,440 Particularly, today we're going to focus on the issue of loss. 30 00:01:51,440 --> 00:01:54,290 How do we avoid losses within the network? 31 00:01:54,290 --> 00:01:56,400 And we'll talk a little bit about this problem 32 00:01:56,400 --> 00:01:58,200 of reordering. 33 00:01:58,200 --> 00:02:00,210 We're going to save the discussion of delays 34 00:02:00,210 --> 00:02:01,930 and congestion for next time. 35 00:02:09,620 --> 00:02:13,780 So the end to end layer in addition 36 00:02:13,780 --> 00:02:16,380 to helping us deal with these limitations of the best effort 37 00:02:16,380 --> 00:02:18,690 network provides a few other features 38 00:02:18,690 --> 00:02:19,890 that we need to mention. 39 00:02:19,890 --> 00:02:27,040 So, the first thing that the end to end layer does 40 00:02:27,040 --> 00:02:30,680 is it provides the ability to multiplex multiple applications 41 00:02:30,680 --> 00:02:32,000 on top of the network. 42 00:02:32,000 --> 00:02:34,010 So the network that we talked about so far 43 00:02:34,010 --> 00:02:35,740 is one in which there are these two 44 00:02:35,740 --> 00:02:38,350 endpoints, to computers that are connected to each other. 45 00:02:38,350 --> 00:02:39,960 And they are transmitting a sequence of messages. 46 00:02:39,960 --> 00:02:41,418 But we haven't really said anything 47 00:02:41,418 --> 00:02:43,440 about how those messages get dispatched 48 00:02:43,440 --> 00:02:45,990 to different applications that are running above the network 49 00:02:45,990 --> 00:02:47,490 layer. 50 00:02:47,490 --> 00:02:55,760 The other thing the end to end layer 51 00:02:55,760 --> 00:02:59,260 provides for us is the ability to, 52 00:02:59,260 --> 00:03:02,330 is fragmentation of messages. 53 00:03:05,870 --> 00:03:09,370 OK, and fragmentation is really about the fact 54 00:03:09,370 --> 00:03:12,800 that the link in itself may have some maximum size 55 00:03:12,800 --> 00:03:15,750 message that it can physically transmit because that's, 56 00:03:15,750 --> 00:03:17,634 say for example, the maximum size message 57 00:03:17,634 --> 00:03:19,550 is how long the sender and receiver can remain 58 00:03:19,550 --> 00:03:21,240 synchronized with each other. 59 00:03:21,240 --> 00:03:23,105 So what the end to end layer often does 60 00:03:23,105 --> 00:03:25,230 is it provides the ability to take a longer message 61 00:03:25,230 --> 00:03:28,210 and fragment it up into smaller chunks or fragments, 62 00:03:28,210 --> 00:03:30,610 and it transmits each of those fragments 63 00:03:30,610 --> 00:03:35,440 independently as a separate message across the network. 64 00:03:35,440 --> 00:03:38,450 So just to illustrate how these things are 65 00:03:38,450 --> 00:03:40,250 dealt with within the end to end layer, 66 00:03:40,250 --> 00:03:41,910 let's look at a little illustration. 67 00:03:41,910 --> 00:03:47,370 So suppose we have some set of applications that are connected 68 00:03:47,370 --> 00:03:48,970 up to the end to end layer. 69 00:03:54,890 --> 00:03:57,690 OK, so these applications, the idea 70 00:03:57,690 --> 00:04:00,340 is going to be that when a message arrives over the end 71 00:04:00,340 --> 00:04:02,950 to end layer, it's going to be dispatched 72 00:04:02,950 --> 00:04:04,960 to one of these applications by looking 73 00:04:04,960 --> 00:04:08,020 at a special number that's in the header of this message that 74 00:04:08,020 --> 00:04:08,520 comes in. 75 00:04:08,520 --> 00:04:13,760 So, this number is often referred to as a port number. 76 00:04:13,760 --> 00:04:15,410 And, each application is going to be 77 00:04:15,410 --> 00:04:17,149 running on one of these ports. 78 00:04:17,149 --> 00:04:19,480 So oftentimes these ports are sort 79 00:04:19,480 --> 00:04:21,089 of running at well-known addresses. 80 00:04:21,089 --> 00:04:23,940 So we talked about these numbers very briefly 81 00:04:23,940 --> 00:04:27,970 earlier, for example, Web servers run at port number 80 82 00:04:27,970 --> 00:04:31,130 in the TCP protocol. 83 00:04:31,130 --> 00:04:35,150 So if you want to contact a Web server at a particular machine, 84 00:04:35,150 --> 00:04:36,620 talk to port 80. 85 00:04:36,620 --> 00:04:39,740 Other times applications will send the port number 86 00:04:39,740 --> 00:04:43,820 that they're listening at in a message where two people will 87 00:04:43,820 --> 00:04:45,950 exchange the port numbers through some out of band 88 00:04:45,950 --> 00:04:49,422 protocol, say by telling your friend in an email 89 00:04:49,422 --> 00:04:51,380 that he should connect your server because it's 90 00:04:51,380 --> 00:04:53,580 running on port X. 91 00:04:53,580 --> 00:04:56,770 So, messages now are going to arrive 92 00:04:56,770 --> 00:04:59,020 into the end to end layer from the network layer. 93 00:04:59,020 --> 00:05:00,170 And these messages are going to have 94 00:05:00,170 --> 00:05:02,003 in their header information about which port 95 00:05:02,003 --> 00:05:03,425 they should be dispatched to. 96 00:05:03,425 --> 00:05:05,800 So the other functionality of the end to end layer I said 97 00:05:05,800 --> 00:05:07,890 is fragmentation. 98 00:05:07,890 --> 00:05:13,490 Then fragmentation is about taking a message that's 99 00:05:13,490 --> 00:05:15,420 being sent down from one of these applications 100 00:05:15,420 --> 00:05:16,930 into the end to end layer. 101 00:05:16,930 --> 00:05:26,370 And then that message on its way to the network layer 102 00:05:26,370 --> 00:05:29,230 gets fragmented up into a number of chunks. 103 00:05:29,230 --> 00:05:31,370 So these are each of these little chunks 104 00:05:31,370 --> 00:05:33,240 in this message is called a fragment. 105 00:05:37,740 --> 00:05:44,570 So these are sort of, so oftentimes one common end 106 00:05:44,570 --> 00:05:46,870 to end layer is one that provides an abstraction that's 107 00:05:46,870 --> 00:05:48,360 called a stream. 108 00:05:48,360 --> 00:05:57,280 So a stream is simply a flow of messages or data 109 00:05:57,280 --> 00:06:00,990 from one endpoint to the other, one application to the other, 110 00:06:00,990 --> 00:06:06,330 and where the segments in that stream are guaranteed 111 00:06:06,330 --> 00:06:09,920 to be delivered, are loss-free. 112 00:06:09,920 --> 00:06:13,470 So there are no missing segments or missing messages. 113 00:06:13,470 --> 00:06:15,360 And they are in order. 114 00:06:15,360 --> 00:06:19,410 So the application knows that the data that it receives 115 00:06:19,410 --> 00:06:22,080 is going to be in the order that the receiver knows 116 00:06:22,080 --> 00:06:24,450 the data it receives is going to be in the order 117 00:06:24,450 --> 00:06:26,390 that the sender sent it out on the channel. 118 00:06:26,390 --> 00:06:28,110 And there won't be any missing messages. 119 00:06:28,110 --> 00:06:30,276 So this sounds like a pretty convenient abstraction. 120 00:06:30,276 --> 00:06:32,390 And it's one that's often used in applications. 121 00:06:32,390 --> 00:06:34,540 And in fact, this stream abstraction 122 00:06:34,540 --> 00:06:37,610 is the attraction that the TCP protocol provides. 123 00:06:37,610 --> 00:06:43,900 OK, so just to sort of make it clear, 124 00:06:43,900 --> 00:06:47,590 I just want to look quickly at a simplified end 125 00:06:47,590 --> 00:06:48,630 to end header format. 126 00:06:48,630 --> 00:06:52,860 So we looked at the header formats at the other layers 127 00:06:52,860 --> 00:06:53,820 last time. 128 00:06:53,820 --> 00:06:55,670 And this is just showing some of the things 129 00:06:55,670 --> 00:06:57,910 that you might expect to see an end to end header. 130 00:06:57,910 --> 00:07:00,346 There are, of course, are additional things 131 00:07:00,346 --> 00:07:01,720 if you go look at the TCP header. 132 00:07:01,720 --> 00:07:03,080 But these are the ones that mostly 133 00:07:03,080 --> 00:07:04,913 matter from the point of view of this class. 134 00:07:04,913 --> 00:07:08,710 So there is a source port which specifies 135 00:07:08,710 --> 00:07:10,210 which port the sender of the message 136 00:07:10,210 --> 00:07:11,776 is listening at on the other side. 137 00:07:11,776 --> 00:07:13,150 There is a destination port which 138 00:07:13,150 --> 00:07:15,840 specifies which port number this message 139 00:07:15,840 --> 00:07:17,670 should be sent to on the receiver side. 140 00:07:17,670 --> 00:07:20,090 There is something called the nonce. 141 00:07:20,090 --> 00:07:22,510 The nonce is just a unique identifier. 142 00:07:22,510 --> 00:07:25,800 It's just a thing that uniquely identifies this message 143 00:07:25,800 --> 00:07:28,740 as far as the conversation between the two endpoints 144 00:07:28,740 --> 00:07:30,940 is concerned. 145 00:07:30,940 --> 00:07:32,340 A common kind of the nonce to use 146 00:07:32,340 --> 00:07:34,030 is just a sequence number that gets 147 00:07:34,030 --> 00:07:36,755 incremented by one every time an additional message is sent. 148 00:07:36,755 --> 00:07:38,630 And then, oftentimes in the end to end layer, 149 00:07:38,630 --> 00:07:40,652 there's also some check some information, 150 00:07:40,652 --> 00:07:42,110 something that allows you to verify 151 00:07:42,110 --> 00:07:44,700 the integrity of the messages that are transmitted out 152 00:07:44,700 --> 00:07:46,000 over the network. 153 00:07:46,000 --> 00:07:48,230 And we do this at the end to end layer. 154 00:07:48,230 --> 00:07:50,630 We saw that the checksum sometimes appeared 155 00:07:50,630 --> 00:07:52,080 in the link layer before. 156 00:07:52,080 --> 00:07:56,840 They also appear at the end to end layer because it's possible 157 00:07:56,840 --> 00:08:00,070 that, as you guys read in the paper about end 158 00:08:00,070 --> 00:08:02,770 to end arguments, oftentimes we want 159 00:08:02,770 --> 00:08:07,226 to verify that the message is correct at the end to end layer 160 00:08:07,226 --> 00:08:09,350 or at the application layer even if we have already 161 00:08:09,350 --> 00:08:11,330 may be verified but that was the case at the link layer 162 00:08:11,330 --> 00:08:13,621 because the message could have been corrupted somewhere 163 00:08:13,621 --> 00:08:16,450 above just the link layer, right? 164 00:08:16,450 --> 00:08:19,680 So this is sort of the abstraction 165 00:08:19,680 --> 00:08:21,270 that the end to end layer provides. 166 00:08:21,270 --> 00:08:24,880 Notice that the header format here doesn't actually include, 167 00:08:24,880 --> 00:08:27,490 for example, the addresses of the endpoints, 168 00:08:27,490 --> 00:08:28,302 the IP addresses. 169 00:08:28,302 --> 00:08:30,510 That's because the IP addresses are in the IP header. 170 00:08:30,510 --> 00:08:33,070 So, remember, this is just the additional information 171 00:08:33,070 --> 00:08:35,289 that's added by the end to end layer, 172 00:08:35,289 --> 00:08:36,789 and is used to dispatch from the end 173 00:08:36,789 --> 00:08:39,669 to end layer to the applications that are running above it. 174 00:08:39,669 --> 00:08:42,409 Once we are dealing with the end to end header, 175 00:08:42,409 --> 00:08:45,220 all the packets have already been transmitted 176 00:08:45,220 --> 00:08:47,340 across the network, and in fact we 177 00:08:47,340 --> 00:08:49,670 don't need to know what the IP address is anymore 178 00:08:49,670 --> 00:08:52,710 because this is happening on the local machine. 179 00:08:52,710 --> 00:08:56,010 All of the applications are running at the same IP address. 180 00:08:56,010 --> 00:09:00,870 OK, so that the other things that we said, so I said today 181 00:09:00,870 --> 00:09:03,310 we're going to focus mostly on the ability of the end 182 00:09:03,310 --> 00:09:05,710 to end layer to mitigate these problems of losses. 183 00:09:05,710 --> 00:09:07,302 So this is sort of the abstraction 184 00:09:07,302 --> 00:09:08,760 that the end to end layer provides. 185 00:09:08,760 --> 00:09:10,176 But what we want to look at now is 186 00:09:10,176 --> 00:09:12,780 how does the end to end layer actually deal with loss? 187 00:09:12,780 --> 00:09:16,260 We're going to talk about two different techniques. 188 00:09:16,260 --> 00:09:19,372 There's two different components to dealing with loss. 189 00:09:19,372 --> 00:09:20,830 So the first thing we want to do is 190 00:09:20,830 --> 00:09:22,950 we want to make sure that no packets get 191 00:09:22,950 --> 00:09:24,824 lost during transmission. 192 00:09:24,824 --> 00:09:26,240 And the way we're going to do that 193 00:09:26,240 --> 00:09:36,640 is providing what we call at least once delivery. 194 00:09:36,640 --> 00:09:39,880 The reason I put at least once in quotes 195 00:09:39,880 --> 00:09:42,760 here is that I'm going to talk you through a protocol. 196 00:09:42,760 --> 00:09:45,030 But, and this protocol is going to guarantee 197 00:09:45,030 --> 00:09:47,650 that a message gets received by the receiver 198 00:09:47,650 --> 00:09:50,270 as long as, for example, the receiver doesn't completely 199 00:09:50,270 --> 00:09:52,650 fail or the network doesn't completely explode. 200 00:09:52,650 --> 00:09:54,442 So it's always possible that messages 201 00:09:54,442 --> 00:09:56,900 can be lost because there can be some physical failure that 202 00:09:56,900 --> 00:09:59,066 makes it impossible for the messages to get through. 203 00:09:59,066 --> 00:10:02,980 But as long as it is possible for the message to get through, 204 00:10:02,980 --> 00:10:05,676 there's a very high probability that the message 205 00:10:05,676 --> 00:10:06,800 will, in fact, get through. 206 00:10:06,800 --> 00:10:08,466 And, if the message doesn't get through, 207 00:10:08,466 --> 00:10:11,230 what this at least once delivery protocol is going to guarantee 208 00:10:11,230 --> 00:10:14,190 is that the receiver knows that the sender may not 209 00:10:14,190 --> 00:10:17,280 have actually received the message, OK? 210 00:10:17,280 --> 00:10:19,322 So, and once we talk about it at least once, 211 00:10:19,322 --> 00:10:20,780 we're going to talk about something 212 00:10:20,780 --> 00:10:24,000 we call at most once delivery. 213 00:10:24,000 --> 00:10:27,359 And the issue with at most once delivery is the at least once 214 00:10:27,359 --> 00:10:28,900 protocol that I'm going to sketch out 215 00:10:28,900 --> 00:10:30,130 is going to generate duplicates. 216 00:10:30,130 --> 00:10:32,463 And we're going to need to make sure that we can get rid 217 00:10:32,463 --> 00:10:33,840 of some of the duplicates. 218 00:10:33,840 --> 00:10:36,170 And these two things together are 219 00:10:36,170 --> 00:10:38,690 going to provide what's known as exactly once 220 00:10:38,690 --> 00:10:40,180 delivery of messages. 221 00:10:42,980 --> 00:10:46,830 OK, so let's start off by talking 222 00:10:46,830 --> 00:10:48,810 about our at least once protocol. 223 00:10:55,850 --> 00:10:57,370 This protocol is going to guarantee 224 00:10:57,370 --> 00:11:01,050 that if at all possible, the message will 225 00:11:01,050 --> 00:11:02,974 be received by the receiver. 226 00:11:02,974 --> 00:11:04,390 And the way we're going to do this 227 00:11:04,390 --> 00:11:05,681 is really very straightforward. 228 00:11:05,681 --> 00:11:08,110 We are just going to have the receiver send a message back 229 00:11:08,110 --> 00:11:10,680 to the sender that says I got the message. 230 00:11:10,680 --> 00:11:12,740 So, the receiver, when it gets the message, 231 00:11:12,740 --> 00:11:15,627 sends what's called an acknowledgment back -- 232 00:11:18,760 --> 00:11:28,000 -- sometimes abbreviated ACK, indicating that the message was 233 00:11:28,000 --> 00:11:30,850 received at the other end. 234 00:11:30,850 --> 00:11:33,100 OK, this is just going to be sent back to the receiver 235 00:11:33,100 --> 00:11:34,380 directly. 236 00:11:34,380 --> 00:11:38,297 So in order to send this acknowledgment, 237 00:11:38,297 --> 00:11:40,380 though, we're going to need a way for the receiver 238 00:11:40,380 --> 00:11:43,642 to refer to the message that the sender sent, right? 239 00:11:43,642 --> 00:11:45,350 So we want the receiver to be able to say 240 00:11:45,350 --> 00:11:49,760 I received this message that you sent to me. 241 00:11:49,760 --> 00:11:51,510 And the simplest way to be able to do that 242 00:11:51,510 --> 00:11:53,395 is to just use this nonce information that's 243 00:11:53,395 --> 00:11:54,020 in the packets. 244 00:11:54,020 --> 00:11:55,940 We said the nonce is a unique identifier 245 00:11:55,940 --> 00:11:59,940 as far as the two endpoints of the conversation are concerned. 246 00:11:59,940 --> 00:12:02,310 So the knowledge man is basically 247 00:12:02,310 --> 00:12:09,680 just going to be the nonce of the message, OK? 248 00:12:09,680 --> 00:12:14,200 So let's look at how this works in a simple example. 249 00:12:14,200 --> 00:12:17,610 So the idea is that the sender at some 250 00:12:17,610 --> 00:12:22,260 point it's going to send a message to the receiver. 251 00:12:22,260 --> 00:12:24,260 And this message is going to contain information 252 00:12:24,260 --> 00:12:27,860 like, well, it's going to have the address of the sender, 253 00:12:27,860 --> 00:12:30,600 the address of the receiver, the ports on both ends the message 254 00:12:30,600 --> 00:12:33,240 is supposed to be sent to, this nonce information that uniquely 255 00:12:33,240 --> 00:12:35,781 identifies the message, and then whatever the data that needs 256 00:12:35,781 --> 00:12:37,200 to go in the message. 257 00:12:37,200 --> 00:12:40,400 Now when it sends this message, what's going to happen 258 00:12:40,400 --> 00:12:42,240 is that the sender is going to keep 259 00:12:42,240 --> 00:12:43,615 this table of pending messages. 260 00:12:43,615 --> 00:12:45,990 So the sender is going to keep a list of all the messages 261 00:12:45,990 --> 00:12:47,830 that it hasn't yet heard acknowledged. 262 00:12:52,140 --> 00:12:54,070 And then at some point, and it's going 263 00:12:54,070 --> 00:12:56,990 to keep, for example, if this message is, 264 00:12:56,990 --> 00:12:59,500 say, the name of this message is one 265 00:12:59,500 --> 00:13:01,780 and the nonce for this message is X, 266 00:13:01,780 --> 00:13:05,030 is going to add that information into its table. 267 00:13:05,030 --> 00:13:06,990 Now at some point later the receiver 268 00:13:06,990 --> 00:13:09,860 is going to send in a knowledge man for this message one back. 269 00:13:09,860 --> 00:13:13,030 And it just going to have the sender and receiver IP 270 00:13:13,030 --> 00:13:16,290 address, the port number of the receiver, 271 00:13:16,290 --> 00:13:18,720 and the nonce, which the sender is 272 00:13:18,720 --> 00:13:21,411 going to use in order to remove this entry from its table. 273 00:13:21,411 --> 00:13:23,910 So once the sender receives an acknowledgment for a message, 274 00:13:23,910 --> 00:13:25,784 it no longer needs to keep any state about it 275 00:13:25,784 --> 00:13:29,020 because it knows that the receiver has received it. 276 00:13:29,020 --> 00:13:30,920 OK, so how does this do us any good? 277 00:13:30,920 --> 00:13:32,352 How is this at least once? 278 00:13:32,352 --> 00:13:34,310 Well, let's see what happens when there is loss 279 00:13:34,310 --> 00:13:36,700 that occurs within the network? 280 00:13:36,700 --> 00:13:40,410 So the idea is very simple. 281 00:13:40,410 --> 00:13:42,300 Suppose that the sender sends out 282 00:13:42,300 --> 00:13:44,480 a message, message two this time, 283 00:13:44,480 --> 00:13:46,120 and that message somehow gets lost 284 00:13:46,120 --> 00:13:47,680 in transit through the network. 285 00:13:47,680 --> 00:13:50,930 So the network drops the message either because of congestion 286 00:13:50,930 --> 00:13:54,360 or because some links failed and it doesn't get through. 287 00:13:54,360 --> 00:13:56,380 The idea is that the sender is going 288 00:13:56,380 --> 00:13:59,494 to keep a timer associated with every message that it sends. 289 00:13:59,494 --> 00:14:01,660 And this timer is going to be a timeout value that's 290 00:14:01,660 --> 00:14:04,080 going to tell the sender when it should retry 291 00:14:04,080 --> 00:14:05,290 transmitting this message. 292 00:14:05,290 --> 00:14:07,920 And the sender is just going to retry transmitting messages 293 00:14:07,920 --> 00:14:10,580 over and over and over again until the message actually 294 00:14:10,580 --> 00:14:11,360 gets through. 295 00:14:11,360 --> 00:14:13,670 So in this case it sets this timer 296 00:14:13,670 --> 00:14:18,470 for time TR1 at the same instant that it sends out this message. 297 00:14:18,470 --> 00:14:22,520 And then when time TR1 arrives in the message hasn't yet 298 00:14:22,520 --> 00:14:25,330 been acknowledged, the sender is, 299 00:14:25,330 --> 00:14:27,900 so after this retry interval time, 300 00:14:27,900 --> 00:14:30,680 the sender is just going to try and retransmit the message. 301 00:14:30,680 --> 00:14:32,300 So now in this case, the receiver 302 00:14:32,300 --> 00:14:33,969 has successfully received the message. 303 00:14:33,969 --> 00:14:35,760 But notice that the sender doesn't actually 304 00:14:35,760 --> 00:14:37,970 know that the receiver has received it. 305 00:14:37,970 --> 00:14:40,040 We can see it from the diagram, but there's 306 00:14:40,040 --> 00:14:42,564 been no feedback that has come from the receiver again. 307 00:14:42,564 --> 00:14:44,230 And now, suppose that the receiver sends 308 00:14:44,230 --> 00:14:46,960 its acknowledgment for this message, and along the way 309 00:14:46,960 --> 00:14:48,972 the acknowledgment gets lost, right? 310 00:14:48,972 --> 00:14:50,430 So this could happen just as easily 311 00:14:50,430 --> 00:14:52,930 as the original message being sent out. 312 00:14:52,930 --> 00:14:57,540 So now in this case, our retry mechanism continues to work. 313 00:14:57,540 --> 00:15:00,720 And after this retry interval and time TR2 is reached, 314 00:15:00,720 --> 00:15:03,490 the message gets resent, and then in this case 315 00:15:03,490 --> 00:15:06,000 finally the message is actually received 316 00:15:06,000 --> 00:15:09,140 and we can go ahead and remove from the pending message list. 317 00:15:09,140 --> 00:15:11,930 So this process, the sender is just 318 00:15:11,930 --> 00:15:14,140 going to continually retry transmitting 319 00:15:14,140 --> 00:15:16,650 these messages until it gets an acknowledgment 320 00:15:16,650 --> 00:15:18,190 from the receiver. 321 00:15:18,190 --> 00:15:19,670 Actually in practice, it's the case 322 00:15:19,670 --> 00:15:22,090 that the receiver will only retry a fixed number of times 323 00:15:22,090 --> 00:15:25,350 because as we said, there are certain situations 324 00:15:25,350 --> 00:15:27,580 in which the network can just be simply unavailable. 325 00:15:27,580 --> 00:15:29,121 Suppose there's no network connection 326 00:15:29,121 --> 00:15:31,879 available to the transmitter to the sender. 327 00:15:31,879 --> 00:15:34,170 Of course at some point it's going to make sense for it 328 00:15:34,170 --> 00:15:35,294 to give up and stop trying. 329 00:15:35,294 --> 00:15:37,790 And then it will report an error to the user. 330 00:15:37,790 --> 00:15:39,760 The other thing to notice about this protocol 331 00:15:39,760 --> 00:15:42,218 that we've described here is that the receiver has received 332 00:15:42,218 --> 00:15:45,320 two copies of this message. 333 00:15:45,320 --> 00:15:48,080 So that seems a little bit problematic, right? 334 00:15:48,080 --> 00:15:51,110 If this is a message that says withdraw $10,000 from your bank 335 00:15:51,110 --> 00:15:53,740 account, we don't probably want to process that message twice, 336 00:15:53,740 --> 00:15:54,240 right? 337 00:15:54,240 --> 00:15:55,540 That might be problematic. 338 00:15:55,540 --> 00:16:01,340 So we're going to address that issue 339 00:16:01,340 --> 00:16:04,100 when we get to talking about at most once delivery. 340 00:16:04,100 --> 00:16:06,460 But just bear in mind for now that these duplicates 341 00:16:06,460 --> 00:16:07,881 can occur. 342 00:16:07,881 --> 00:16:10,130 There is another subtlety with this protocol that I've 343 00:16:10,130 --> 00:16:12,625 described here, though. 344 00:16:12,625 --> 00:16:14,000 Does anybody see something that's 345 00:16:14,000 --> 00:16:15,690 a little bit suspicious about this diagram 346 00:16:15,690 --> 00:16:18,148 that I've shown here, a little bit weird about the way I've 347 00:16:18,148 --> 00:16:22,240 shown it? 348 00:16:22,240 --> 00:16:23,320 Yeah? 349 00:16:23,320 --> 00:16:24,480 OK, right, good. 350 00:16:24,480 --> 00:16:26,280 So there's this question about, how 351 00:16:26,280 --> 00:16:29,030 are you going to set the retry interval for these messages, 352 00:16:29,030 --> 00:16:29,530 right? 353 00:16:29,530 --> 00:16:32,260 So what I've shown here is that the retry interval is short, 354 00:16:32,260 --> 00:16:34,860 and the first time we sent and received this message, in fact 355 00:16:34,860 --> 00:16:37,430 the time it took us to do that appeared to be quite 356 00:16:37,430 --> 00:16:39,560 long on this diagram, right? 357 00:16:39,560 --> 00:16:42,770 And so in fact what would've happened if we had done 358 00:16:42,770 --> 00:16:45,830 this is that the sender would have retransmitted this message 359 00:16:45,830 --> 00:16:48,700 several times even though the receiver had actually received 360 00:16:48,700 --> 00:16:50,400 the message, and the acknowledgment 361 00:16:50,400 --> 00:16:53,190 was on the way back to us correctly. 362 00:16:53,190 --> 00:16:55,469 It's just that we didn't wait long enough 363 00:16:55,469 --> 00:16:57,260 for that acknowledgment to come back to us. 364 00:16:57,260 --> 00:16:58,430 So, there's this question about, well, 365 00:16:58,430 --> 00:17:00,804 how are we going to pick this timer interval so that it's 366 00:17:00,804 --> 00:17:03,820 appropriate for the network that we're running on. 367 00:17:03,820 --> 00:17:08,630 And this turns out to be kind of an interesting and challenging 368 00:17:08,630 --> 00:17:09,130 problem. 369 00:17:16,380 --> 00:17:19,960 So there's this question about, how long 370 00:17:19,960 --> 00:17:21,220 do I wait before a retry? 371 00:17:29,080 --> 00:17:31,370 So a simple answer for how long we should wait 372 00:17:31,370 --> 00:17:34,480 is, well, whatever the round-trip time on the network 373 00:17:34,480 --> 00:17:37,630 is, however long it takes for a message to reach the receiver 374 00:17:37,630 --> 00:17:40,780 and then for the knowledge meant to be sent back to the sender; 375 00:17:40,780 --> 00:17:44,320 so we call that the round-trip time up or the RTT. 376 00:17:44,320 --> 00:17:49,390 So, we'd like to wait at least RTT, right? 377 00:17:49,390 --> 00:17:53,120 But the problem is that RTT is this round-trip time 378 00:17:53,120 --> 00:17:56,250 is not necessarily going to be constant over the whole 379 00:17:56,250 --> 00:17:58,030 lifetime of the network. 380 00:17:58,030 --> 00:17:59,930 So let me show you what I mean. 381 00:17:59,930 --> 00:18:03,480 This is a plot of some round-trip time information 382 00:18:03,480 --> 00:18:05,170 from a wide area wireless link. 383 00:18:05,170 --> 00:18:08,060 So these transit times are very long 384 00:18:08,060 --> 00:18:09,990 here over this link, their sort of order 385 00:18:09,990 --> 00:18:14,740 of thousands of milliseconds. 386 00:18:14,740 --> 00:18:18,400 So the average transmission time is 2.4 seconds here. 387 00:18:18,400 --> 00:18:21,580 The standard deviation, which is a measure 388 00:18:21,580 --> 00:18:23,760 of the variance between these different samples 389 00:18:23,760 --> 00:18:25,610 is 1.5 seconds. 390 00:18:25,610 --> 00:18:28,510 So there's a lot of bouncing around of this signal. 391 00:18:28,510 --> 00:18:33,090 And so it's not as though the round-trip time; 392 00:18:33,090 --> 00:18:34,740 expecting the round-trip time to simply 393 00:18:34,740 --> 00:18:37,430 be a single constant value isn't a very good idea. 394 00:18:37,430 --> 00:18:39,720 So if we want to set the timeout just 395 00:18:39,720 --> 00:18:45,099 for RTT, that's going to cause us, 396 00:18:45,099 --> 00:18:46,640 if you think about this for a minute, 397 00:18:46,640 --> 00:18:50,880 if we set it just to be RTT, which is say for example may be 398 00:18:50,880 --> 00:18:54,630 the average round-trip time that we measured 399 00:18:54,630 --> 00:19:01,130 in a signal like this, well, some significant proportion 400 00:19:01,130 --> 00:19:04,870 of the time we're going to be above the RTT, right, 401 00:19:04,870 --> 00:19:07,710 because just picking the average, 402 00:19:07,710 --> 00:19:11,140 there's going to be many samples that are above the RTT. 403 00:19:11,140 --> 00:19:14,550 So instead we want to do RTT plus some slop 404 00:19:14,550 --> 00:19:19,240 value, some adjustment factor that 405 00:19:19,240 --> 00:19:22,050 gives us a little bit of extra sort of leeway in how long 406 00:19:22,050 --> 00:19:23,040 we wait. 407 00:19:23,040 --> 00:19:24,498 But of course we don't want to wait 408 00:19:24,498 --> 00:19:26,260 too long because if we wait too long then 409 00:19:26,260 --> 00:19:28,820 we're not going to actually retransmit the messages that 410 00:19:28,820 --> 00:19:31,190 were in fact lost. 411 00:19:31,190 --> 00:19:34,070 OK, so let's look at how, so that's 412 00:19:34,070 --> 00:19:35,700 sort of a simple intuitive argument 413 00:19:35,700 --> 00:19:37,145 for how we should do this. 414 00:19:37,145 --> 00:19:39,270 What I want to just do now is just quickly take you 415 00:19:39,270 --> 00:19:41,910 through the way that these round-trip times are done, 416 00:19:41,910 --> 00:19:44,760 actually, these round-trip times are 417 00:19:44,760 --> 00:19:48,410 estimated in the TCP protocol. 418 00:19:48,410 --> 00:19:53,030 And the way this is done is really pretty straightforward. 419 00:19:53,030 --> 00:20:01,690 The idea is that we want to estimate the average RTT. 420 00:20:01,690 --> 00:20:03,120 And then we also want to estimate 421 00:20:03,120 --> 00:20:07,380 the sort of variance which is going to be our slop number. 422 00:20:07,380 --> 00:20:10,370 OK, so one way we could compute the average RTT 423 00:20:10,370 --> 00:20:12,484 is to keep this sort of set of samples 424 00:20:12,484 --> 00:20:13,650 of all the round-trip times. 425 00:20:13,650 --> 00:20:15,925 So I have maybe 20 points, I have 426 00:20:15,925 --> 00:20:17,550 whatever it is, 20 points here that are 427 00:20:17,550 --> 00:20:19,130 samples of the round-trip time. 428 00:20:19,130 --> 00:20:21,317 So I could take this set of 20 numbers 429 00:20:21,317 --> 00:20:22,650 and compute the average of them. 430 00:20:22,650 --> 00:20:24,691 And then I could recompute the average every time 431 00:20:24,691 --> 00:20:26,231 a new number comes in. 432 00:20:26,231 --> 00:20:27,730 The problem with that is that I have 433 00:20:27,730 --> 00:20:30,165 to keep this window of all the averages around. 434 00:20:30,165 --> 00:20:31,540 So instead, what we want to do is 435 00:20:31,540 --> 00:20:33,470 to have some way of sort of updating 436 00:20:33,470 --> 00:20:35,040 the average without having to keep 437 00:20:35,040 --> 00:20:37,150 all the previous values around. 438 00:20:37,150 --> 00:20:39,230 And there's a simple technique that's commonly 439 00:20:39,230 --> 00:20:42,777 used in computer systems called an exponentially weighted 440 00:20:42,777 --> 00:20:44,360 moving average, which is a way that we 441 00:20:44,360 --> 00:20:47,880 can keep track of this average with just a single number. 442 00:20:47,880 --> 00:20:49,740 So this is the EWMA. 443 00:20:49,740 --> 00:21:00,110 And what the EWMA does is given a set of samples, 444 00:21:00,110 --> 00:21:03,780 say S1 up to some most recent sample S 445 00:21:03,780 --> 00:21:10,920 gnu, what the EWMA does is incrementally 446 00:21:10,920 --> 00:21:14,080 adjust the RTT according to the following formula. 447 00:21:14,080 --> 00:21:17,410 So, as the [new/gnu?] RTT is going to be equal to one minus 448 00:21:17,410 --> 00:21:23,160 alpha, so these samples are samples of round-trip times, 449 00:21:23,160 --> 00:21:25,170 OK, like this number here. 450 00:21:25,170 --> 00:21:26,640 So, these are numbers that we have 451 00:21:26,640 --> 00:21:28,860 observed over time as messages have been transmitted 452 00:21:28,860 --> 00:21:29,880 back and forth. 453 00:21:29,880 --> 00:21:34,280 We're going to take some number one minus alpha times S 454 00:21:34,280 --> 00:21:37,970 gnu, our newly observed roundtrip time. 455 00:21:37,970 --> 00:21:42,050 And we're going to add to that some alpha times 456 00:21:42,050 --> 00:21:45,000 the old round-trip time. 457 00:21:45,000 --> 00:21:50,010 OK, so what this does is basically 458 00:21:50,010 --> 00:21:54,600 it computes the RTT as some weighted combination 459 00:21:54,600 --> 00:21:57,921 of the old roundtrip time and the newly observed roundtrip 460 00:21:57,921 --> 00:21:58,420 time. 461 00:21:58,420 --> 00:22:01,280 And, if you think about this for a minute, if we make alpha, 462 00:22:01,280 --> 00:22:06,560 so alpha in this case is going to be some number between zero 463 00:22:06,560 --> 00:22:09,120 and one. 464 00:22:09,120 --> 00:22:12,510 And if you think about alpha being zero, if alpha is zero, 465 00:22:12,510 --> 00:22:15,770 then the newly computed round-trip time 466 00:22:15,770 --> 00:22:17,950 is just equal to S gnu, right? 467 00:22:17,950 --> 00:22:21,879 And, if alpha is one, then the newly computed roundtrip time 468 00:22:21,879 --> 00:22:24,420 is just equal to whatever the old round-trip time was, right? 469 00:22:24,420 --> 00:22:26,360 So, the new sample has no effect. 470 00:22:26,360 --> 00:22:29,620 So, as we move very alpha between these two extremes, 471 00:22:29,620 --> 00:22:32,650 we are going to weight the new roundtrip time more or less 472 00:22:32,650 --> 00:22:33,150 heavily. 473 00:22:33,150 --> 00:22:37,360 OK, so this is not going to perfectly compute the average 474 00:22:37,360 --> 00:22:38,767 of the samples over time. 475 00:22:38,767 --> 00:22:40,600 But it's going to give us some estimate that 476 00:22:40,600 --> 00:22:42,875 sort of varies with time. 477 00:22:42,875 --> 00:22:44,500 The other thing we said we wanted to do 478 00:22:44,500 --> 00:22:46,790 was compute what the slop factor is. 479 00:22:46,790 --> 00:22:49,250 And the slop factor, we just want 480 00:22:49,250 --> 00:22:52,340 this to be some measure of the variance of this signal. 481 00:22:52,340 --> 00:22:55,070 So in particular, what we want it to be is, 482 00:22:55,070 --> 00:22:59,480 I'm just going to push this up so I can write, 483 00:22:59,480 --> 00:23:03,220 slop is going to be equal to some factor 484 00:23:03,220 --> 00:23:08,740 beta times some variants of this, some number 485 00:23:08,740 --> 00:23:09,490 that the variance. 486 00:23:09,490 --> 00:23:11,380 And what I mean by variance is simply 487 00:23:11,380 --> 00:23:22,085 the difference between the predicted and actual round-trip 488 00:23:22,085 --> 00:23:22,585 times. 489 00:23:25,260 --> 00:23:30,090 So if our formula says that this round-trip time, given 490 00:23:30,090 --> 00:23:35,990 a sample, the round-trip time should be 10 ms. 491 00:23:35,990 --> 00:23:37,810 And the next sample comes in and it 492 00:23:37,810 --> 00:23:40,980 says the actual round-trip time was 20 ms. 493 00:23:40,980 --> 00:23:44,880 Then the variance, we would say that sort of this deviation, 494 00:23:44,880 --> 00:23:48,024 the difference between those two things would be 10 ms. 495 00:23:48,024 --> 00:23:49,190 So let's see how this works. 496 00:23:49,190 --> 00:23:51,440 I'll show you now the pseudocode for how this actually 497 00:23:51,440 --> 00:23:52,550 works in the Internet. 498 00:23:52,550 --> 00:23:54,467 And it should be pretty clear what's going on. 499 00:23:54,467 --> 00:23:55,925 So what we're going to do is we are 500 00:23:55,925 --> 00:23:57,900 going to keep a set of variables, one of which 501 00:23:57,900 --> 00:23:59,790 is called SRTT. 502 00:23:59,790 --> 00:24:03,510 So this is almost exactly what the TCP protocol does. 503 00:24:03,510 --> 00:24:07,320 So we're going to have SRTT, which is the current roundtrip 504 00:24:07,320 --> 00:24:07,904 time estimate. 505 00:24:07,904 --> 00:24:10,361 And then we're going to have this thing we're going to call 506 00:24:10,361 --> 00:24:12,120 RTT [DEV?], which is the deviation, 507 00:24:12,120 --> 00:24:15,790 the current estimate of sort of the variance of this round-trip 508 00:24:15,790 --> 00:24:16,496 time. 509 00:24:16,496 --> 00:24:18,120 And we're going to initialize these two 510 00:24:18,120 --> 00:24:20,280 numbers to be something that seems reasonable. 511 00:24:20,280 --> 00:24:22,490 We might say the round-trip time is 100 ms, 512 00:24:22,490 --> 00:24:26,440 and this RTT DEV is 50 ms. 513 00:24:26,440 --> 00:24:27,870 And now what we're going to do is 514 00:24:27,870 --> 00:24:30,500 every time a new one of these samples of the round-trip time 515 00:24:30,500 --> 00:24:33,440 comes in, we're going to call this calc RTT function. 516 00:24:33,440 --> 00:24:34,970 What the calc RTT function is going 517 00:24:34,970 --> 00:24:38,720 to do isn't going to update the old, 518 00:24:38,720 --> 00:24:42,430 update the round-trip time using this formula 519 00:24:42,430 --> 00:24:43,830 that we've seen here. 520 00:24:43,830 --> 00:24:46,940 And in the case of TCP, people have sort of experimented 521 00:24:46,940 --> 00:24:50,800 with different values, and sort of the number that is typically 522 00:24:50,800 --> 00:24:54,980 used is that a number that is commonly used 523 00:24:54,980 --> 00:24:59,260 is that sort of used alpha, you set alpha to be seven eighths. 524 00:24:59,260 --> 00:25:02,350 So that means that you sort of add in one eighth 525 00:25:02,350 --> 00:25:05,590 of the new number, and use seven eighths of the old number. 526 00:25:05,590 --> 00:25:08,450 So, a new number that varies a lot 527 00:25:08,450 --> 00:25:12,010 isn't going to change the overall round-trip time, 528 00:25:12,010 --> 00:25:15,160 estimate of the round-trip time terribly dramatically. 529 00:25:15,160 --> 00:25:17,680 And we're going to compute the deviation as I've shown here. 530 00:25:17,680 --> 00:25:20,220 We're going to take the absolute value of it. 531 00:25:20,220 --> 00:25:22,750 And then, we're going to keep some running estimate 532 00:25:22,750 --> 00:25:24,300 of the round-trip time again using 533 00:25:24,300 --> 00:25:26,652 one of these sort of exponentially weighted things. 534 00:25:26,652 --> 00:25:28,110 So in this case we're going to wait 535 00:25:28,110 --> 00:25:31,400 with this setting, the value of the weight 536 00:25:31,400 --> 00:25:33,620 here to three quarters. 537 00:25:33,620 --> 00:25:36,142 OK, so that's a simple way to compute the round-trip time. 538 00:25:36,142 --> 00:25:38,600 And now, given the computation of the round-trip time, what 539 00:25:38,600 --> 00:25:40,560 we need to do is to compute the timeout value 540 00:25:40,560 --> 00:25:41,650 that we should use. 541 00:25:41,650 --> 00:25:45,040 So what we said is the timeout value you want to use 542 00:25:45,040 --> 00:25:47,110 is RTT plus some slop. 543 00:25:47,110 --> 00:25:51,210 And, in the case of TCP, a commonly used slop value 544 00:25:51,210 --> 00:25:53,980 might be four times the estimate of the deviation. 545 00:25:53,980 --> 00:25:55,620 See, the idea is that we want the slop 546 00:25:55,620 --> 00:25:58,980 value to be larger if the round-trip time varies more. 547 00:25:58,980 --> 00:26:00,980 If the round-trip time is practically constant, 548 00:26:00,980 --> 00:26:02,230 we don't want it to vary much. 549 00:26:02,230 --> 00:26:09,720 We are sort of happy; if the round-trip time is practically 550 00:26:09,720 --> 00:26:14,250 constant, then the timeout shouldn't be very much longer 551 00:26:14,250 --> 00:26:16,130 than that round-trip time because that's 552 00:26:16,130 --> 00:26:18,213 going to suggest we are going to be waiting longer 553 00:26:18,213 --> 00:26:19,470 than we need to time out. 554 00:26:19,470 --> 00:26:21,482 If the round-trip time varies very dramatically, 555 00:26:21,482 --> 00:26:23,440 we need to wait a relatively long time in order 556 00:26:23,440 --> 00:26:26,550 to be sure that the message in fact 557 00:26:26,550 --> 00:26:29,584 has been lost as opposed to simply taking 558 00:26:29,584 --> 00:26:31,000 a long time for the acknowledgment 559 00:26:31,000 --> 00:26:36,550 to get back to us. 560 00:26:36,550 --> 00:26:40,050 OK, so what we've seen so far now 561 00:26:40,050 --> 00:26:46,050 is we've seen how we can build up at least once semantics 562 00:26:46,050 --> 00:26:47,610 using acknowledgments. 563 00:26:47,610 --> 00:26:50,720 And we talked about how we can go ahead and set these timers 564 00:26:50,720 --> 00:26:54,370 in order to allow us to calculate the round-trip time 565 00:26:54,370 --> 00:26:56,480 for a message. 566 00:26:56,480 --> 00:26:59,780 And these timers are going to allow us to sort of decide when 567 00:26:59,780 --> 00:27:02,110 we should retransmit a message. 568 00:27:02,110 --> 00:27:06,290 But we also saw how we have a little bit of a problem 569 00:27:06,290 --> 00:27:10,350 in the at least once protocol. 570 00:27:10,350 --> 00:27:12,990 And the problem is that we can generate duplicates. 571 00:27:12,990 --> 00:27:14,960 So in order to avoid duplicates, we 572 00:27:14,960 --> 00:27:16,975 need to introduce this notion of at most once. 573 00:27:19,960 --> 00:27:22,545 OK, so the idea with at most once 574 00:27:22,545 --> 00:27:24,170 is that we want to suppress duplicates. 575 00:27:35,510 --> 00:27:39,990 And duplicate suppression turns out it works a lot like the way 576 00:27:39,990 --> 00:27:44,030 that acknowledgments work on the receiver side 577 00:27:44,030 --> 00:27:45,170 or on the sender side. 578 00:27:45,170 --> 00:27:46,840 So on the receiver side we're going 579 00:27:46,840 --> 00:27:49,260 to keep a table of all of the nonces, 580 00:27:49,260 --> 00:27:50,850 of all the messages that we've heard, 581 00:27:50,850 --> 00:27:56,260 and we're only going to process a message when we haven't 582 00:27:56,260 --> 00:27:57,600 already processed that message. 583 00:27:57,600 --> 00:28:00,016 And we're going to tell whether we've already processed it 584 00:28:00,016 --> 00:28:01,790 by looking in this table of nonces. 585 00:28:01,790 --> 00:28:03,700 So let's look at an example. 586 00:28:03,700 --> 00:28:05,130 So here we are. 587 00:28:05,130 --> 00:28:06,870 This is sort of showing you the protocol, 588 00:28:06,870 --> 00:28:09,682 a stage in the at least once protocol 589 00:28:09,682 --> 00:28:10,640 that we were in before. 590 00:28:10,640 --> 00:28:12,600 So we've already sent message one. 591 00:28:12,600 --> 00:28:15,060 It's been successfully acknowledged. 592 00:28:15,060 --> 00:28:18,100 And you notice that we have this table of nonces, 593 00:28:18,100 --> 00:28:20,990 received messages, that is that the receiver. 594 00:28:20,990 --> 00:28:24,150 And in this table, we have received this message 595 00:28:24,150 --> 00:28:26,490 with nonce X. 596 00:28:26,490 --> 00:28:30,260 OK, so now when the sender starts 597 00:28:30,260 --> 00:28:34,380 to decide to send a message two with nonce Y, it sends it out. 598 00:28:34,380 --> 00:28:36,270 The message doesn't arrive. 599 00:28:36,270 --> 00:28:37,460 We time out. 600 00:28:37,460 --> 00:28:40,090 We retry. 601 00:28:40,090 --> 00:28:43,410 And this time the message is successfully received. 602 00:28:43,410 --> 00:28:46,489 So what we do is we go ahead and add the nonce for this message 603 00:28:46,489 --> 00:28:47,780 into the table on the receiver. 604 00:28:49,957 --> 00:28:52,540 And then the receiver goes ahead and sends the acknowledgment. 605 00:28:52,540 --> 00:28:55,050 But the acknowledgment is lost. 606 00:28:55,050 --> 00:28:59,880 Again, the sender times out, resends the message. 607 00:28:59,880 --> 00:29:02,300 And this time, when the receiver receives this message, 608 00:29:02,300 --> 00:29:05,652 it's going to look it up in the receive messages table. 609 00:29:05,652 --> 00:29:07,610 And it's going to see that this is a duplicate. 610 00:29:07,610 --> 00:29:09,480 It already has seen a message with nonce Y. 611 00:29:09,480 --> 00:29:11,270 So, it's not going to process this. 612 00:29:11,270 --> 00:29:13,154 But it needs to still be sure that it 613 00:29:13,154 --> 00:29:14,820 sends the acknowledgment of the message. 614 00:29:14,820 --> 00:29:16,220 So it doesn't actually do anything. 615 00:29:16,220 --> 00:29:17,928 It doesn't actually process this message. 616 00:29:17,928 --> 00:29:19,770 It doesn't pass it up to the application 617 00:29:19,770 --> 00:29:21,480 so the application can look at it. 618 00:29:21,480 --> 00:29:23,260 But it still sends the acknowledgment 619 00:29:23,260 --> 00:29:25,990 so that the receiver knows that the message has been received. 620 00:29:28,530 --> 00:29:31,512 OK, so this is fine. 621 00:29:31,512 --> 00:29:33,220 But if you think about this for a second, 622 00:29:33,220 --> 00:29:36,110 this table of received messages is now 623 00:29:36,110 --> 00:29:38,834 just going to be kind of growing without bound, right? 624 00:29:38,834 --> 00:29:40,500 Because every time we receive a message, 625 00:29:40,500 --> 00:29:44,780 we're going to add a new message to this table of nonces, right? 626 00:29:44,780 --> 00:29:45,810 And this is a problem. 627 00:29:45,810 --> 00:29:48,590 I mean if we're sending thousands of messages 628 00:29:48,590 --> 00:29:51,310 out over the network, then this table 629 00:29:51,310 --> 00:29:54,310 is going to become very, very large. 630 00:29:54,310 --> 00:29:55,970 So what are we going to do about it? 631 00:29:55,970 --> 00:30:00,780 Well, we're going to do sort of again the obvious thing. 632 00:30:00,780 --> 00:30:02,880 We're going to have the sender send 633 00:30:02,880 --> 00:30:05,090 some additional information that lets 634 00:30:05,090 --> 00:30:08,680 the receiver know which messages the receiver has actually 635 00:30:08,680 --> 00:30:09,670 heard. 636 00:30:09,670 --> 00:30:11,750 So a common way that this might be done 637 00:30:11,750 --> 00:30:14,200 is to simply, along with each message that 638 00:30:14,200 --> 00:30:17,100 gets sent, piggyback a little bit of information, 639 00:30:17,100 --> 00:30:19,630 for example that contains the list of messages 640 00:30:19,630 --> 00:30:24,780 that the sender knows that the receiver has actually received. 641 00:30:24,780 --> 00:30:27,060 Right, so when the sender receives an acknowledgment 642 00:30:27,060 --> 00:30:30,190 for a message, it knows that it's never 643 00:30:30,190 --> 00:30:33,300 going to have to request, never going 644 00:30:33,300 --> 00:30:34,932 to resend the message anymore. 645 00:30:34,932 --> 00:30:36,640 And so there's no reason for the receiver 646 00:30:36,640 --> 00:30:39,340 to keep that message in its table of received messages 647 00:30:39,340 --> 00:30:41,470 because it's never going to be asked to acknowledge 648 00:30:41,470 --> 00:30:42,520 that message again. 649 00:30:42,520 --> 00:30:45,800 So we can attach a little bit of information to the messages 650 00:30:45,800 --> 00:30:48,550 that we send that indicates sort of which messages we 651 00:30:48,550 --> 00:30:51,380 have definitely completed up to this point. 652 00:30:51,380 --> 00:30:58,360 OK, so this is a simple way in which 653 00:30:58,360 --> 00:31:01,180 we can sort of eliminate these messages that 654 00:31:01,180 --> 00:31:02,900 are hanging around. 655 00:31:02,900 --> 00:31:05,080 These messages that are sort of left 656 00:31:05,080 --> 00:31:09,830 in our table of received messages 657 00:31:09,830 --> 00:31:12,370 are sometimes referred to as tombstones, 658 00:31:12,370 --> 00:31:14,010 which is kind of a funny name. 659 00:31:14,010 --> 00:31:17,700 But the idea is that there are these messages that 660 00:31:17,700 --> 00:31:20,337 are kind of, that are sort of remnants 661 00:31:20,337 --> 00:31:22,670 of a dead message that's hanging around that we're never 662 00:31:22,670 --> 00:31:23,961 going to need to process again. 663 00:31:23,961 --> 00:31:26,304 But it might just be sitting in this table. 664 00:31:26,304 --> 00:31:28,470 And we are able to get rid of some of the tombstones 665 00:31:28,470 --> 00:31:31,340 by piggybacking this information on to the ends of the messages 666 00:31:31,340 --> 00:31:32,710 that we retransmit. 667 00:31:32,710 --> 00:31:35,800 But you have to realize that there's always 668 00:31:35,800 --> 00:31:38,450 going to be a few messages left over in this receive messages 669 00:31:38,450 --> 00:31:43,020 table because if we use this piggybacking technique 670 00:31:43,020 --> 00:31:45,940 because we are piggybacking a list of done messages 671 00:31:45,940 --> 00:31:47,950 onto messages that are sent. 672 00:31:47,950 --> 00:31:50,947 So if the sender never sends any more messages, 673 00:31:50,947 --> 00:31:52,530 then the receiver is never going to be 674 00:31:52,530 --> 00:31:54,770 able to eliminate any of the tombstones 675 00:31:54,770 --> 00:31:56,275 from its list of received messages. 676 00:31:59,680 --> 00:32:04,850 OK, so now what we've seen is a simple way 677 00:32:04,850 --> 00:32:09,530 to provide this sort of notion of at least once and at most 678 00:32:09,530 --> 00:32:11,140 once delivery. 679 00:32:11,140 --> 00:32:16,430 So as I said before, taken together, 680 00:32:16,430 --> 00:32:23,020 this is sometimes called an exactly once protocol. 681 00:32:23,020 --> 00:32:25,450 And this variant of this protocol that we've seen 682 00:32:25,450 --> 00:32:27,700 is called a lockstep protocol. 683 00:32:27,700 --> 00:32:39,800 OK, so it's called lockstep because the sender and receiver 684 00:32:39,800 --> 00:32:41,170 are operating in lockstep. 685 00:32:41,170 --> 00:32:42,830 The sender sends a message, and then it 686 00:32:42,830 --> 00:32:45,430 waits for the receiver to send in a knowledge meant before it 687 00:32:45,430 --> 00:32:47,150 sends any additional messages. 688 00:32:47,150 --> 00:32:51,660 Right, so we are always sort of sitting here waiting for, 689 00:32:51,660 --> 00:32:54,350 the sender is basically spending a lot of time 690 00:32:54,350 --> 00:32:57,090 idle waiting to receive an acknowledgment. 691 00:32:57,090 --> 00:33:00,010 If you think about what this means 692 00:33:00,010 --> 00:33:08,220 in terms of the throughput of the network, 693 00:33:08,220 --> 00:33:09,720 it's kind of a limitation. 694 00:33:09,720 --> 00:33:11,095 So let's do a simple calculation. 695 00:33:16,210 --> 00:33:20,682 So suppose that we said that packets, the segments that 696 00:33:20,682 --> 00:33:23,140 are being sent in this network, these things that are being 697 00:33:23,140 --> 00:33:24,860 sent back and forth in being acknowledged 698 00:33:24,860 --> 00:33:27,460 are, say, 512 bytes large. 699 00:33:30,660 --> 00:33:32,594 So, suppose we said that it takes 700 00:33:32,594 --> 00:33:34,010 the round-trip time in the network 701 00:33:34,010 --> 00:33:37,200 is, say, 100 ms, which might be a common roundtrip 702 00:33:37,200 --> 00:33:41,320 time in a traditional network, well, the throughput 703 00:33:41,320 --> 00:33:44,270 of this network is going to be, the maximum throughput 704 00:33:44,270 --> 00:33:46,520 of this network is going to be limited by this number, 705 00:33:46,520 --> 00:33:49,210 512 bytes divided by 100 ms. 706 00:33:49,210 --> 00:33:51,660 The round-trip time is 100 ms. 707 00:33:51,660 --> 00:33:54,870 And so we have to wait 100 ms between each transmission 708 00:33:54,870 --> 00:33:55,790 of messages. 709 00:33:55,790 --> 00:33:58,440 And the sort of size of a message 710 00:33:58,440 --> 00:34:01,960 is, if the message is 512 bytes, then we're 711 00:34:01,960 --> 00:34:04,420 going to be able to send ten of these messages per second. 712 00:34:04,420 --> 00:34:10,070 So we're going to send sort of approximately 50 kb per second. 713 00:34:10,070 --> 00:34:12,389 OK, that's not very fast, right? 714 00:34:12,389 --> 00:34:15,179 If we want to send, modern networks 715 00:34:15,179 --> 00:34:19,050 are often capable of sending tens or hundreds of megabytes, 716 00:34:19,050 --> 00:34:20,139 megabits a second. 717 00:34:20,139 --> 00:34:23,290 So we would like to be able to make this number higher. 718 00:34:26,190 --> 00:34:28,600 So this is a bit of a performance problem. 719 00:34:34,754 --> 00:34:36,170 And the way we're going to do this 720 00:34:36,170 --> 00:34:39,250 is by making it so that the sender doesn't 721 00:34:39,250 --> 00:34:41,975 wait to receive its acknowledgments before it goes 722 00:34:41,975 --> 00:34:43,100 and sends the next message. 723 00:34:43,100 --> 00:34:45,915 So the sender is going to start sending the next message 724 00:34:45,915 --> 00:34:47,790 before it's even heard the first message even 725 00:34:47,790 --> 00:34:49,080 being acknowledged. 726 00:34:49,080 --> 00:35:02,970 So we're going to have multiple overlapping transmissions, OK? 727 00:35:05,670 --> 00:35:11,510 So let's see a really simple example of how this works. 728 00:35:11,510 --> 00:35:14,300 So the idea is now that the sender, 729 00:35:14,300 --> 00:35:16,160 it's going to send a message. 730 00:35:16,160 --> 00:35:19,185 And then before it's even heard the knowledge meant 731 00:35:19,185 --> 00:35:21,310 from the receiver, it's going to go ahead and start 732 00:35:21,310 --> 00:35:22,143 sending the message. 733 00:35:22,143 --> 00:35:23,799 At the same time, the receiver can 734 00:35:23,799 --> 00:35:25,340 go ahead and acknowledge the messages 735 00:35:25,340 --> 00:35:26,480 that have already been sent. 736 00:35:26,480 --> 00:35:27,938 So you sort of see what's happening 737 00:35:27,938 --> 00:35:31,130 here is that as time passes, the additional messages are being 738 00:35:31,130 --> 00:35:33,210 sent, and the acknowledgment for those messages 739 00:35:33,210 --> 00:35:35,111 start being sent as soon as possible. 740 00:35:35,111 --> 00:35:36,610 So we have a whole bunch of messages 741 00:35:36,610 --> 00:35:41,100 that are kind of flying back and forth within this network. 742 00:35:41,100 --> 00:35:44,276 And I've only shown the sort of yellow, red, and blue messages 743 00:35:44,276 --> 00:35:45,650 actually being acknowledged here. 744 00:35:45,650 --> 00:35:47,110 The white messages aren't being acknowledged. 745 00:35:47,110 --> 00:35:49,401 But of course there would be acknowledgments [pulling?] 746 00:35:49,401 --> 00:35:51,770 for those as well. 747 00:35:51,770 --> 00:35:53,990 So this seems really good. 748 00:35:53,990 --> 00:35:55,920 Right now we can send messages basically 749 00:35:55,920 --> 00:35:59,270 as fast as we can cram them onto the network. 750 00:35:59,270 --> 00:36:02,725 And we sort of don't have to wait for the acknowledgments 751 00:36:02,725 --> 00:36:03,600 to come back anymore. 752 00:36:06,810 --> 00:36:08,471 So in effect, what we've said is now 753 00:36:08,471 --> 00:36:09,970 the throughput is simply constrained 754 00:36:09,970 --> 00:36:13,120 by how fast we can cram the bytes onto the network. 755 00:36:13,120 --> 00:36:16,870 But this is a little bit of an oversimplification, right, 756 00:36:16,870 --> 00:36:20,064 because this is sort of ignoring what 757 00:36:20,064 --> 00:36:22,730 it is that the receiver, suppose the sender is just sending data 758 00:36:22,730 --> 00:36:23,540 as fast as it can. 759 00:36:23,540 --> 00:36:25,604 Well the receiver has to receive that data, 760 00:36:25,604 --> 00:36:26,770 has to do something with it. 761 00:36:26,770 --> 00:36:27,680 It has to process it. 762 00:36:27,680 --> 00:36:29,980 It has to take some action on it, right? 763 00:36:29,980 --> 00:36:32,540 And so it's very possible or very likely in fact 764 00:36:32,540 --> 00:36:36,089 that if we cram data at the receiver in this way, 765 00:36:36,089 --> 00:36:38,380 that the receiver is going to become overloaded, right? 766 00:36:38,380 --> 00:36:41,340 The receiver has some limited amount 767 00:36:41,340 --> 00:36:44,900 of data that it can buffer or that it can hold on to. 768 00:36:44,900 --> 00:36:47,580 And we are going to overflow those buffers. 769 00:36:47,580 --> 00:36:49,310 And we're going to create a problem. 770 00:36:49,310 --> 00:36:51,260 So what we want to do is to have some way 771 00:36:51,260 --> 00:36:53,730 to allow the receiver to kind of throttle 772 00:36:53,730 --> 00:36:55,730 the transmission of the sender to ask the sender 773 00:36:55,730 --> 00:36:58,415 to back off a little bit, and not send so aggressively. 774 00:37:02,570 --> 00:37:05,930 So we call this -- 775 00:37:05,930 --> 00:37:10,510 -- the technique that we're going to use is called flow 776 00:37:10,510 --> 00:37:11,830 control. 777 00:37:11,830 --> 00:37:14,960 And it's basically just a way in which the receiver 778 00:37:14,960 --> 00:37:17,140 can tell the sender what great it 779 00:37:17,140 --> 00:37:18,720 would like to receive data at. 780 00:37:18,720 --> 00:37:30,105 OK, so this is going to be sort of receiver driven feedback. 781 00:37:35,940 --> 00:37:40,040 And we're going to look at two techniques 782 00:37:40,040 --> 00:37:41,600 basically for doing this. 783 00:37:41,600 --> 00:37:45,030 The first one is a technique called fixed windows. 784 00:37:45,030 --> 00:37:50,140 And the other technique is a technique 785 00:37:50,140 --> 00:37:51,500 called sliding windows. 786 00:37:51,500 --> 00:37:58,920 OK, and what we mean by window here: 787 00:37:58,920 --> 00:38:06,970 a window is simply the size of the data that the receiver can 788 00:38:06,970 --> 00:38:10,472 accept, the number of messages that the receiver can accept -- 789 00:38:16,610 --> 00:38:24,440 -- can accept at one time. 790 00:38:27,800 --> 00:38:30,840 So the idea is we're going to send a window's worth of data 791 00:38:30,840 --> 00:38:33,080 all continuously. 792 00:38:33,080 --> 00:38:34,864 And then once the receiver says that it's 793 00:38:34,864 --> 00:38:36,280 done processing that window, we're 794 00:38:36,280 --> 00:38:41,290 going to be able to go ahead and send a next window to it. 795 00:38:41,290 --> 00:38:43,450 So this first scheme that we're going to look at 796 00:38:43,450 --> 00:38:48,630 is called the fixed windows scheme. 797 00:38:48,630 --> 00:38:51,030 And the idea is really very straightforward. 798 00:38:51,030 --> 00:38:54,260 The sender and the receiver at the beginning of communication 799 00:38:54,260 --> 00:38:55,560 can negotiate. 800 00:38:55,560 --> 00:38:57,350 They're going to exchange some information 801 00:38:57,350 --> 00:38:59,180 about what the window size is. 802 00:38:59,180 --> 00:39:01,650 So the sender is going to request 803 00:39:01,650 --> 00:39:03,370 the connection, the open, and then 804 00:39:03,370 --> 00:39:07,650 the receiver is going to say, for example, OK, let's go ahead 805 00:39:07,650 --> 00:39:10,050 and start having this conversation, and by the way, 806 00:39:10,050 --> 00:39:13,230 my window size is four segments. 807 00:39:13,230 --> 00:39:16,495 So now, the sender can send four segments all at once, 808 00:39:16,495 --> 00:39:18,620 and the receiver can go ahead and acknowledge them. 809 00:39:18,620 --> 00:39:21,810 So we can have four segments that are sort of in flight 810 00:39:21,810 --> 00:39:23,450 at any one time. 811 00:39:23,450 --> 00:39:26,790 And then after those messages have all been acknowledged, 812 00:39:26,790 --> 00:39:31,050 the receiver is going to have to sort of chew on those messages 813 00:39:31,050 --> 00:39:36,380 and process them for a little while, during which time 814 00:39:36,380 --> 00:39:39,084 basically the sender is simply waiting. 815 00:39:39,084 --> 00:39:40,500 It's simply sitting there waiting. 816 00:39:40,500 --> 00:39:43,330 But notice that we were at least able to, 817 00:39:43,330 --> 00:39:45,720 the sender was able to do a little bit of extra work. 818 00:39:45,720 --> 00:39:47,636 It was able to send all four of these messages 819 00:39:47,636 --> 00:39:49,700 to simultaneously. 820 00:39:49,700 --> 00:39:51,540 And then when the receiver has finished 821 00:39:51,540 --> 00:39:53,081 processing these messages, it's going 822 00:39:53,081 --> 00:39:56,310 to go ahead and ask for some additional set of messages 823 00:39:56,310 --> 00:39:58,860 to be transmitted out over the network. 824 00:39:58,860 --> 00:40:01,600 So notice that there is a little assumption here 825 00:40:01,600 --> 00:40:04,510 which is that acknowledgments are being sent 826 00:40:04,510 --> 00:40:07,530 before the sort of receiver has actually 827 00:40:07,530 --> 00:40:08,960 finished processing the messages. 828 00:40:08,960 --> 00:40:11,274 So the protocol that I'm showing here 829 00:40:11,274 --> 00:40:12,940 is that the receiver receives a message, 830 00:40:12,940 --> 00:40:16,180 and it immediately acknowledges it without, 831 00:40:16,180 --> 00:40:18,390 even though it hasn't actually, the application 832 00:40:18,390 --> 00:40:20,360 hasn't necessarily processed this message yet. 833 00:40:20,360 --> 00:40:22,910 And the reason we want to do this is that application 834 00:40:22,910 --> 00:40:25,470 process, remember it's already hard enough for us 835 00:40:25,470 --> 00:40:31,240 to estimate this round-trip time using this EWMA approach. 836 00:40:31,240 --> 00:40:34,120 And so, trying to sort of also estimate 837 00:40:34,120 --> 00:40:36,780 how long it would take the application to process the data 838 00:40:36,780 --> 00:40:39,250 would further complicate this process of setting timers. 839 00:40:39,250 --> 00:40:43,030 So we usually just sending knowledge meant right away. 840 00:40:43,030 --> 00:40:44,910 OK, so this is the fixed size windows scheme. 841 00:40:44,910 --> 00:40:47,180 And it's nice because now basically 842 00:40:47,180 --> 00:40:52,391 we've set this thing up so that the sender can sort of send 843 00:40:52,391 --> 00:40:54,640 more messages without waiting for the acknowledgments. 844 00:40:54,640 --> 00:40:57,597 But the receiver has a way that it can kind of throttle 845 00:40:57,597 --> 00:40:58,680 how fast the sender sends. 846 00:40:58,680 --> 00:41:01,450 It knows that it only has buffers for four messages. 847 00:41:01,450 --> 00:41:04,230 So it says my window size is four. 848 00:41:04,230 --> 00:41:06,670 But we would like to do a little bit better, right? 849 00:41:06,670 --> 00:41:09,670 In particular, we would like to avoid this sort of situation 850 00:41:09,670 --> 00:41:15,170 where, both so in this case we sort of have long periods where 851 00:41:15,170 --> 00:41:16,670 the network is kind of sitting idle, 852 00:41:16,670 --> 00:41:20,140 where we are not using available bandwidth within the network 853 00:41:20,140 --> 00:41:22,340 because we're sort of waiting. 854 00:41:22,340 --> 00:41:25,290 The sender has, perhaps, data to send, 855 00:41:25,290 --> 00:41:27,760 but it hasn't received the message to send, 856 00:41:27,760 --> 00:41:30,390 the receiver can accept more messages. 857 00:41:30,390 --> 00:41:33,380 And the receiver may be has processed some of the messages 858 00:41:33,380 --> 00:41:36,450 that it's received, but it hasn't yet sent this message; 859 00:41:36,450 --> 00:41:38,920 it hasn't yet asked the sender to go ahead and send 860 00:41:38,920 --> 00:41:40,210 any additional data. 861 00:41:40,210 --> 00:41:43,990 So the way that we're going to fix this is to use something 862 00:41:43,990 --> 00:41:46,230 called the sliding window technique. 863 00:41:46,230 --> 00:41:49,690 And the idea is that when the receiver, rather than 864 00:41:49,690 --> 00:41:52,530 the receiver waiting until it is processed the whole window's 865 00:41:52,530 --> 00:41:57,510 worth of data, when the receiver processes 866 00:41:57,510 --> 00:42:00,420 each message within its window, so if this window is more 867 00:42:00,420 --> 00:42:03,180 messages big, once it's processed the first message, 868 00:42:03,180 --> 00:42:05,775 it's going to go ahead and indicate that to the sender 869 00:42:05,775 --> 00:42:07,650 so that the sender can then go ahead and send 870 00:42:07,650 --> 00:42:09,710 additional messages. 871 00:42:09,710 --> 00:42:13,030 So rather than sort of getting four new messages 872 00:42:13,030 --> 00:42:14,510 at a time, what we're going to do 873 00:42:14,510 --> 00:42:16,530 is we're going to send our first four messages. 874 00:42:16,530 --> 00:42:18,560 And then we're going to just send one additional message 875 00:42:18,560 --> 00:42:19,060 at a time. 876 00:42:19,060 --> 00:42:21,600 So that's why we say the window is sliding, because we're 877 00:42:21,600 --> 00:42:24,160 going to sort of allow the sender 878 00:42:24,160 --> 00:42:25,829 to send an additional message whenever 879 00:42:25,829 --> 00:42:28,120 it is that the receiver is finished processing just one 880 00:42:28,120 --> 00:42:29,380 message. 881 00:42:29,380 --> 00:42:31,220 And the way we are going to do this again, 882 00:42:31,220 --> 00:42:35,540 we're going to initially negotiate a window size. 883 00:42:35,540 --> 00:42:38,317 And then when the sender starts sending, 884 00:42:38,317 --> 00:42:39,650 it's going to do the same thing. 885 00:42:39,650 --> 00:42:41,790 It's going to send all four of these messages. 886 00:42:41,790 --> 00:42:44,040 I've sort of halted this animation in the middle of it 887 00:42:44,040 --> 00:42:45,790 so that I can show you an intermediate step. 888 00:42:45,790 --> 00:42:47,430 But what would really be happening here 889 00:42:47,430 --> 00:42:49,840 is the sender would sort of send all the messages that 890 00:42:49,840 --> 00:42:52,210 were in the window, and then the receiver 891 00:42:52,210 --> 00:42:54,070 would begin processing them. 892 00:42:54,070 --> 00:42:58,840 So the receiver begins processing the first message. 893 00:42:58,840 --> 00:43:02,180 So suppose it finishes processing segment one 894 00:43:02,180 --> 00:43:08,100 before it receives this segment two from the sender. 895 00:43:08,100 --> 00:43:12,030 So now what it can do is in its acknowledgment for segment two, 896 00:43:12,030 --> 00:43:13,900 it can piggyback again using this idea, 897 00:43:13,900 --> 00:43:15,800 it can stick a little bit of information 898 00:43:15,800 --> 00:43:19,950 on to the knowledge meant that says, oh, and by the way, 899 00:43:19,950 --> 00:43:22,090 I have finished processing one of these messages. 900 00:43:22,090 --> 00:43:24,340 You can go ahead and send one more additional message. 901 00:43:24,340 --> 00:43:29,164 You can slide the window by one, OK? 902 00:43:29,164 --> 00:43:31,330 So I'm going to hit the next step of this animation. 903 00:43:31,330 --> 00:43:34,620 And it's going to zip by really fast. 904 00:43:34,620 --> 00:43:37,130 I'll explain what's happening, but don't 905 00:43:37,130 --> 00:43:42,310 try and worry too much about exactly following the details. 906 00:43:42,310 --> 00:43:48,960 OK, so now what happens is that the receiver sort of continues 907 00:43:48,960 --> 00:43:51,040 to process these messages as it arrives, 908 00:43:51,040 --> 00:43:54,250 and then it continues to piggyback 909 00:43:54,250 --> 00:43:57,690 this information about the fact that it has finished sending 910 00:43:57,690 --> 00:43:59,956 some messages onto the acknowledgments, 911 00:43:59,956 --> 00:44:01,330 finished processing some messages 912 00:44:01,330 --> 00:44:02,970 onto the acknowledgments. 913 00:44:02,970 --> 00:44:06,420 If the receiver doesn't have any acknowledgments to send, 914 00:44:06,420 --> 00:44:08,560 which is the case for these last two messages 915 00:44:08,560 --> 00:44:10,720 that it sent out here that I've labeled send more, 916 00:44:10,720 --> 00:44:13,680 it may need to send these sort of slide 917 00:44:13,680 --> 00:44:16,971 the window messages out by itself without acknowledgment. 918 00:44:16,971 --> 00:44:18,970 So here it sends a couple of additional messages 919 00:44:18,970 --> 00:44:23,039 that say go ahead and send me some more data. 920 00:44:23,039 --> 00:44:24,580 OK so in this way now what we've done 921 00:44:24,580 --> 00:44:29,640 is we've managed to make it so that the sender can 922 00:44:29,640 --> 00:44:32,380 send additional information before all 923 00:44:32,380 --> 00:44:35,690 of the sort of messages in the initial window 924 00:44:35,690 --> 00:44:37,430 were processed by the receiver. 925 00:44:37,430 --> 00:44:42,770 So you see that before the sender sends, 926 00:44:42,770 --> 00:44:45,130 before the receiver actually requests, 927 00:44:45,130 --> 00:44:48,670 sends a message requesting a whole new window worth of data, 928 00:44:48,670 --> 00:44:52,480 so you see now that some of the sort of, go ahead and send 929 00:44:52,480 --> 00:44:55,060 more messages from the receiver arrive 930 00:44:55,060 --> 00:45:02,420 at the sender after the time that the sender starts sending 931 00:45:02,420 --> 00:45:04,907 messages, this fifth and sixth message to go ahead 932 00:45:04,907 --> 00:45:05,490 and processed. 933 00:45:05,490 --> 00:45:07,632 So we've managed to sort of increase 934 00:45:07,632 --> 00:45:09,090 the amount of concurrent processing 935 00:45:09,090 --> 00:45:12,230 that we can do in this network. 936 00:45:12,230 --> 00:45:14,490 But there still are periods where 937 00:45:14,490 --> 00:45:17,190 the network is sort of idle where 938 00:45:17,190 --> 00:45:20,510 the sender and receiver are sort of not transmitting data. 939 00:45:20,510 --> 00:45:24,037 So we haven't done quite as good a job as maybe we would like. 940 00:45:24,037 --> 00:45:26,620 And the reason we haven't done quite as good a job as maybe we 941 00:45:26,620 --> 00:45:32,100 would like is when the receiver, so 942 00:45:32,100 --> 00:45:33,890 the property that we would like to enforce 943 00:45:33,890 --> 00:45:38,730 is that when the receiver says go ahead and send me 944 00:45:38,730 --> 00:45:39,320 a new message. 945 00:45:39,320 --> 00:45:41,310 When the receiver says slide the window by one, 946 00:45:41,310 --> 00:45:45,190 by the time that the next message to process 947 00:45:45,190 --> 00:45:48,890 arrives from the sender, we would like the receiver 948 00:45:48,890 --> 00:45:53,200 to not have reached the point where it's idle, 949 00:45:53,200 --> 00:45:54,140 where it has to wait. 950 00:45:54,140 --> 00:45:55,598 So we'd like the receivers buffered 951 00:45:55,598 --> 00:45:59,200 to be big enough such that by the time its request for more 952 00:45:59,200 --> 00:46:04,590 data reaches the sender, and by the time the sender's 953 00:46:04,590 --> 00:46:07,800 response comes back, we would like the receiver to still 954 00:46:07,800 --> 00:46:10,280 have some data to process, whereas what's happened here 955 00:46:10,280 --> 00:46:13,570 is that the receiver finished processing all four 956 00:46:13,570 --> 00:46:18,310 messages in its buffer before this next message came back 957 00:46:18,310 --> 00:46:19,920 with additional data for the receiver 958 00:46:19,920 --> 00:46:21,570 to process from the sender. 959 00:46:21,570 --> 00:46:24,320 Right, so basically the problem was that the receiver's buffer 960 00:46:24,320 --> 00:46:28,790 wasn't quite large enough for it to be able to continuously 961 00:46:28,790 --> 00:46:34,762 process data; it didn't have quite enough data 962 00:46:34,762 --> 00:46:36,470 for it to be able to continuously process 963 00:46:36,470 --> 00:46:39,670 while it waited for the additional data 964 00:46:39,670 --> 00:46:43,830 to arrive from the sender. 965 00:46:43,830 --> 00:46:48,110 What this suggests that we want is 966 00:46:48,110 --> 00:46:52,020 to set this buffer size, to set the size of the window 967 00:46:52,020 --> 00:46:57,140 to be the appropriate size in order for the receiver 968 00:46:57,140 --> 00:46:59,090 to be able to sort of continuously process 969 00:46:59,090 --> 00:47:04,246 information if at all possible. 970 00:47:04,246 --> 00:47:06,870 So there's this question about, how do we pick the window size? 971 00:47:09,700 --> 00:47:13,880 So let's assume, so the problem we have 972 00:47:13,880 --> 00:47:22,070 is that small windows imply underutilization 973 00:47:22,070 --> 00:47:26,150 of the network, OK, because we have 974 00:47:26,150 --> 00:47:28,850 both the sender and receiver sort of sitting, waiting. 975 00:47:28,850 --> 00:47:32,079 There's times when there's no data that's being transferred 976 00:47:32,079 --> 00:47:32,870 across the network. 977 00:47:35,510 --> 00:47:38,790 So the question is then, how big should we make the window? 978 00:47:44,850 --> 00:47:51,340 And what we said is we want the window size to be greater than 979 00:47:51,340 --> 00:47:52,715 the amount of time -- 980 00:47:58,050 --> 00:48:02,320 We want it to be long enough so that the receiver which, 981 00:48:02,320 --> 00:48:04,450 say for example, if the receiver can processed 982 00:48:04,450 --> 00:48:07,800 some number of messages, rate messages per second, 983 00:48:07,800 --> 00:48:11,360 OK, the receiver can process this many messages, 984 00:48:11,360 --> 00:48:14,960 we want its buffer to be large enough 985 00:48:14,960 --> 00:48:19,910 that if it processes that many messages per second, 986 00:48:19,910 --> 00:48:22,800 that the amount of time for additional messages for it 987 00:48:22,800 --> 00:48:25,430 to process, that it will still have messages 988 00:48:25,430 --> 00:48:28,170 to process by the time additional messages arrive 989 00:48:28,170 --> 00:48:29,210 from the sender. 990 00:48:29,210 --> 00:48:35,320 So the amount of time it takes for additional messages 991 00:48:35,320 --> 00:48:37,180 to arrive from the sender from the time 992 00:48:37,180 --> 00:48:41,880 that this guy first since this OK to send more message, right, 993 00:48:41,880 --> 00:48:43,960 is one round-trip time of the network. 994 00:48:43,960 --> 00:48:48,650 So it takes one round-trip time of the network for the receiver 995 00:48:48,650 --> 00:48:51,530 to receive additional messages to process from the sender, 996 00:48:51,530 --> 00:48:54,230 and a number of messages that will process 997 00:48:54,230 --> 00:48:57,220 during that round-trip time is whatever its message processing 998 00:48:57,220 --> 00:49:00,630 rate is times the round-trip time of the network. 999 00:49:00,630 --> 00:49:03,020 And so, therefore, this is sort of ideally 1000 00:49:03,020 --> 00:49:06,720 how we would set the window size in this network. 1001 00:49:06,720 --> 00:49:08,330 Of course, we talked about before how 1002 00:49:08,330 --> 00:49:10,880 it's tricky to estimate this sort of EWMA thing 1003 00:49:10,880 --> 00:49:12,720 that we do to estimate the window size 1004 00:49:12,720 --> 00:49:14,850 is not a perfect estimator. 1005 00:49:14,850 --> 00:49:17,950 But we're going to try and sort of, this 1006 00:49:17,950 --> 00:49:22,250 is going to be a good choice for a window size to use. 1007 00:49:22,250 --> 00:49:25,220 And so, typically the receiver is 1008 00:49:25,220 --> 00:49:28,100 going to try and sort of use some rough estimate of what 1009 00:49:28,100 --> 00:49:30,920 it thinks the round-trip time is and the rate at which it 1010 00:49:30,920 --> 00:49:36,130 can process messages when it informs the sender, the window 1011 00:49:36,130 --> 00:49:39,360 size at the initiation of the connection. 1012 00:49:39,360 --> 00:49:42,270 OK, so this basically is going to wrap up 1013 00:49:42,270 --> 00:49:46,650 our discussion of the end-to-end layer, or of the sort of loss 1014 00:49:46,650 --> 00:49:48,410 recovery issues in the end to end layer. 1015 00:49:48,410 --> 00:49:52,370 What we're going to talk about next time is this issue of how 1016 00:49:52,370 --> 00:49:53,780 we deal with congestion, right? 1017 00:49:53,780 --> 00:49:59,310 So we said that in one of these networks, 1018 00:49:59,310 --> 00:50:02,180 there can be all these delays due to queuing, 1019 00:50:02,180 --> 00:50:06,580 and that these delays can introduce additional loss. 1020 00:50:06,580 --> 00:50:08,080 And we call these delays congestion. 1021 00:50:08,080 --> 00:50:09,490 And so what we're going to talk about next time 1022 00:50:09,490 --> 00:50:11,390 is how we actually deal with congestion 1023 00:50:11,390 --> 00:50:13,430 and how we respond to congestion. 1024 00:50:13,430 --> 00:50:15,910 OK so we'll see you on Wednesday.