WEBVTT 00:00:04.850 --> 00:00:09.750 SPEAKER: Hello and welcome back to the second part of lecture 2 00:00:09.750 --> 00:00:13.370 which is about the transport layer. 00:00:13.910 --> 00:00:20.560 The transport layer segments application data into transportable chunks 00:00:20.560 --> 00:00:27.330 for transmission and also reassembles segments as required 00:00:27.330 --> 00:00:34.930 on the receiver side the transport layer uses port numbers. 00:00:34.980 --> 00:00:40.327 We also refer to those as ports for short 00:00:40.327 --> 00:00:46.350 to track individual conversations and identify applications. 00:00:46.410 --> 00:00:52.190 It is important to not confuse these port numbers or ports 00:00:52.190 --> 00:00:57.260 with physical ports on network devices such as switches or routers. 00:00:57.930 --> 00:01:02.070 Unfortunately we use the same term for both 00:01:02.110 --> 00:01:06.030 but based on the context it's it's usually clear 00:01:06.570 --> 00:01:09.330 what is meant or what it is referring to. 00:01:10.530 --> 00:01:14.760 The transport layer provides reliability if required. 00:01:15.030 --> 00:01:18.384 Well it depends on the kind of transfer protocol that is used 00:01:19.014 --> 00:01:23.220 and we do have different transport layer protocols 00:01:23.220 --> 00:01:26.460 so we can cater to different requirements of application. 00:01:26.520 --> 00:01:33.470 And since the transport layer is responsible for transporting data 00:01:33.470 --> 00:01:36.790 from the source to the destination 00:01:36.790 --> 00:01:42.684 we also often refer to it as an end to end concept. 00:01:47.740 --> 00:01:49.740 Alright. 00:01:49.740 --> 00:01:56.080 A very important concept on the transport layer is port numbers. 00:01:56.620 --> 00:02:03.530 So port numbers don't exist physically. It's not a physical port. 00:02:04.270 --> 00:02:07.700 They are a logical concept used by operating systems 00:02:07.700 --> 00:02:11.380 for the identification of different applications. 00:02:12.680 --> 00:02:17.300 Ports are identical but some are actually recognized 00:02:17.300 --> 00:02:19.790 as specific applications for example. 00:02:19.920 --> 00:02:24.500 We talked about this in the first part of the lecture DCP port 80 00:02:24.540 --> 00:02:30.660 is recognised as a HTTP port 53 three can be UDP or DCP 00:02:30.660 --> 00:02:33.930 to recognise it's DNS and so on 00:02:33.930 --> 00:02:36.650 Some applications can also have multiple port numbers 00:02:36.650 --> 00:02:42.350 for example HTTP can also use other port numbers such as 8080. 00:02:42.350 --> 00:02:47.820 And down here in the example you, so if you figured it out 00:02:47.820 --> 00:02:50.130 Here you see two or more examples. 00:02:50.130 --> 00:02:56.214 So for electronic mail we have port 110 for example 00:02:56.214 --> 00:03:01.310 if we use the proper three protocol and Internet chat 00:03:01.310 --> 00:03:06.130 Internet chat application might use Port 531. 00:03:06.620 --> 00:03:15.923 OK, and the port numbers they are actually encoded in the transport layer headers. 00:03:25.640 --> 00:03:31.440 The port numbers are sixteen bit integer values. 00:03:31.560 --> 00:03:36.660 So the range is 0 to 65,535 00:03:37.710 --> 00:03:41.040 and this range is actually separated into three different regions. 00:03:43.230 --> 00:03:46.350 So three classes of ports. 00:03:46.350 --> 00:03:49.920 We have what's called the well known ports. 00:03:49.920 --> 00:03:54.250 Those are the ports from 0 to 1023. 00:03:54.250 --> 00:03:56.630 They're used for common services and applications. 00:03:56.640 --> 00:04:05.890 So HTTP port 80 is one example port 53 for DNS is another example 00:04:06.610 --> 00:04:14.690 or SDP we have port 25, it's well known port for that protocol 00:04:14.690 --> 00:04:17.840 Then above that range of well-known ports NOTE Paragraph 00:04:17.840 --> 00:04:26.690 we have the range of registered ports which range from 1024 to 49,151 00:04:26.690 --> 00:04:31.460 So those are ports for less common use services so applications. 00:04:31.580 --> 00:04:37.630 Couple of examples here, so OpenVPN uses Port 1194 00:04:37.700 --> 00:04:45.890 CIP which is used in the context of voice over IP uses port 5060. 00:04:47.130 --> 00:04:50.370 And above that range we have what's called 00:04:50.520 --> 00:04:58.230 dynamic or private ports so all the ports, 49,151 until the end of the range. 00:04:58.230 --> 00:05:03.870 They're dynamic ports and they're used for client initiated sessions. 00:05:03.930 --> 00:05:10.540 So these ports are dynamically assigned to client applications. 00:05:11.830 --> 00:05:16.370 And if you want to know more there's a full list available 00:05:16.370 --> 00:05:22.250 you can go to that Wikipedia page. 00:05:22.470 --> 00:05:24.820 Alright, so here's another example on the slide, 00:05:24.820 --> 00:05:32.250 So in this example we have clients that use private ports to initiate sessions. 00:05:33.160 --> 00:05:37.000 And we have some uh applications you're running on 00:05:37.140 --> 00:05:40.670 well known ports and... 00:05:40.910 --> 00:05:46.220 Yeah. Keep in mind the source port does not need to match the destination port. 00:05:46.220 --> 00:05:52.010 Some protocols where that is the case or maybe the case 00:05:52.080 --> 00:05:56.060 many probably from applications that are peer to peer applications 00:05:56.570 --> 00:06:02.300 but in general the source code does not need to match 00:06:02.300 --> 00:06:06.350 destination port and is often different. In this example down here 00:06:06.350 --> 00:06:11.920 we have one server that runs an HTTP server port 80 00:06:11.920 --> 00:06:17.420 and SMCP server port 25, and we have two clients 00:06:17.450 --> 00:06:21.490 client one on the side, client two on the other side 00:06:21.490 --> 00:06:26.770 and a client who makes an HTTP request to the server 00:06:26.770 --> 00:06:32.860 and it picks a random port out of this dynamic range 00:06:32.920 --> 00:06:38.380 which is here in this example port 49,152. 00:06:38.520 --> 00:06:43.460 And then of course the HTTP request must be sent to the port 00:06:43.460 --> 00:06:46.904 on which the server application is listening 00:06:46.904 --> 00:06:53.890 and that's port 80 of course and the server responds. 00:06:54.200 --> 00:06:57.439 So we assume that that HTTP request goes to your server 00:06:57.439 --> 00:06:59.690 and the server responds. 00:06:59.690 --> 00:07:03.941 The server response obviously then comes from source port 80 00:07:03.941 --> 00:07:06.910 and it goes to the clients port. 00:07:06.950 --> 00:07:10.640 So the destination port will be 49,152 00:07:11.060 --> 00:07:14.910 And basically the same thing happens over here with clients two 00:07:14.910 --> 00:07:17.780 who wants to send an email. 00:07:18.060 --> 00:07:21.860 The client has selected a dynamic port here of the range 00:07:22.250 --> 00:07:27.772 port 51152 and for the request the destination port is the port, 00:07:27.772 --> 00:07:30.780 the well known port of the SCDP so port 25 00:07:31.430 --> 00:07:34.010 and then when the response comes back from the server 00:07:34.010 --> 00:07:39.530 the response comes from port twenty five and it goes to 00:07:39.530 --> 00:07:44.440 that dynamic port that the client put in the source profile 00:07:44.440 --> 00:07:52.040 of the request which is Port 51152 so hopefully this makes 00:07:52.040 --> 00:07:57.140 the concept of dynamic ports and well-known ports clearer. 00:07:57.830 --> 00:08:03.908 So let's move on to the transport layer protocols that we will discuss. 00:08:03.908 --> 00:08:06.170 In this part of the lecture we will talk about 00:08:06.170 --> 00:08:10.580 the two most common transport layer protocols 00:08:10.580 --> 00:08:16.000 the Transmission Control Protocol, TCP and the User Data protocol, UDP. 00:08:16.000 --> 00:08:19.970 TCP is used when the delivery of data must be reliable 00:08:20.000 --> 00:08:23.510 for example filed downloads, for feature streaming , 00:08:23.510 --> 00:08:27.590 for loading web pages. Address UDP is used when 00:08:27.590 --> 00:08:33.030 the delivery of data must be timely and doesn't need to be reliable. 00:08:33.110 --> 00:08:38.840 So things like voice over IP, video communications 00:08:38.840 --> 00:08:41.930 especially real time sort of video communications 00:08:41.930 --> 00:08:45.550 they make use of UDP as well as online games 00:08:45.550 --> 00:08:49.790 where delay is to be avoided. 00:08:50.000 --> 00:08:55.530 So in fact first person shooter games they are usually based on UDP. 00:08:55.530 --> 00:08:58.960 There are other transport protocols. 00:08:59.230 --> 00:09:05.880 So it is actually not just TCP and UDP but these other protocols 00:09:05.880 --> 00:09:07.900 are not that widely used. 00:09:07.900 --> 00:09:13.013 So two examples are Stream Control Transmission Protocol, SCTP. 00:09:13.013 --> 00:09:19.790 Actually SCTP is fairly well used in the some of the 00:09:20.840 --> 00:09:24.770 Telcom companies because they use that as transport protocol 00:09:24.770 --> 00:09:28.330 for signalling. That's just used in the signaling network 00:09:28.330 --> 00:09:33.060 but in a wider internet it is not very widely used. 00:09:33.580 --> 00:09:36.490 We also have the Datagram Congestion Control Protocol 00:09:36.490 --> 00:09:42.370 DCCP, another transport protocol that's not very widely used. 00:09:43.480 --> 00:09:49.201 So in the remainder of this part we'll talk about a TTP protocol first 00:09:49.201 --> 00:09:54.095 because it is way more complicated and it's a lot more to say, 00:09:55.070 --> 00:10:00.160 and then we'll talk about UDP which is actually a fairly simple protocol 00:10:00.240 --> 00:10:05.914 and then we'll end up with a little bit of a comparison between the two 00:10:07.390 --> 00:10:12.890 and for which type of applications we should use TCP 00:10:12.890 --> 00:10:18.490 and for which we should use UDP, We'll discuss that at the end. 00:10:18.540 --> 00:10:23.398 Alright let's talk about TCP. 00:10:25.730 --> 00:10:29.270 TCP is a connection oriented protocol. 00:10:29.280 --> 00:10:33.272 It means that the communications between two devices 00:10:33.272 --> 00:10:38.429 must be explicitly initiated and terminated. 00:10:38.960 --> 00:10:41.780 Not all transport layer protocols are connection oriented 00:10:41.780 --> 00:10:45.160 so UDP is not connection oriented. 00:10:45.580 --> 00:10:52.473 So the first thing to establish a TCP connction 00:10:53.553 --> 00:10:59.448 is a handshake process that's known as a three way handshake 00:10:59.448 --> 00:11:04.530 and consists of three steps or three segments that are sent around 00:11:04.530 --> 00:11:07.950 and those are illustrated in this figure here. 00:11:08.580 --> 00:11:12.130 So clearly identify but three numbers one two three. 00:11:12.270 --> 00:11:16.580 So at a first step the initiator of the connection which is 00:11:16.580 --> 00:11:20.700 off the client will send a SEE to the other side 00:11:21.860 --> 00:11:26.460 of the server if the server receive the SEE 00:11:26.460 --> 00:11:31.100 the server will respond with the SYN AC AC for acknowledgment 00:11:31.820 --> 00:11:40.070 and then the handshake is completed with another act sent by A here 00:11:40.070 --> 00:11:43.160 over to B. 00:11:43.160 --> 00:11:47.500 After those three packets have been exchanged 00:11:47.500 --> 00:11:52.240 the TCP connection will sort of move into an established state 00:11:52.270 --> 00:11:59.800 and then data can be exchanged between the two sides okay. 00:11:59.830 --> 00:12:03.410 So this is the way TCP connections are setup. 00:12:04.680 --> 00:12:09.570 On the next slide we'll talk about how connections 00:12:09.570 --> 00:12:15.350 are terminated so after a conversation is complete 00:12:16.240 --> 00:12:21.740 the connection is terminated using either three or four steps. 00:12:22.270 --> 00:12:26.390 These steps illustrated this little picture down here. 00:12:26.390 --> 00:12:31.270 And so what happens is when a connection is terminated 00:12:31.270 --> 00:12:35.220 one side that wants to terminate will send what's called a FIN. 00:12:35.260 --> 00:12:39.390 The other side will receive the FIN and send it back. 00:12:40.390 --> 00:12:46.560 And sometime later will and also sent a FIN and finally 00:12:47.680 --> 00:12:52.120 our station A here will send an AC for that FIN 00:12:52.140 --> 00:12:55.360 as received a B and at this point in time here 00:12:55.360 --> 00:13:01.420 the connection is completely terminated. 00:13:02.140 --> 00:13:08.020 So this is either a three way or a four way process because 00:13:09.130 --> 00:13:13.910 in many cases the AC here is sent by B at the FIN 00:13:14.080 --> 00:13:17.590 they can be combined into a single segment. 00:13:17.590 --> 00:13:20.150 So we actually only need three segments, A will send FIN 00:13:20.300 --> 00:13:26.510 B will send a combined AC FIN and then A will send back AC. 00:13:26.510 --> 00:13:34.020 But in some cases we actually may have the full sort of four step process. 00:13:36.760 --> 00:13:43.100 And on the next sort of slide I will discuss why 00:13:43.100 --> 00:13:47.290 we actually need a sort of slightly more complicated process. 00:13:47.290 --> 00:13:54.220 The fourth step process rather than just having three messages. 00:13:54.220 --> 00:14:02.530 So here's two questions for you regarding the setup and tear down of TCP connections 00:14:02.730 --> 00:14:06.360 Why do we actually need a three way handshake? 00:14:06.450 --> 00:14:09.060 isn't two handshakes sufficient? 00:14:09.060 --> 00:14:13.210 So two handshakes as in A to send a signal to B 00:14:13.210 --> 00:14:16.750 and B responds back. 00:14:16.750 --> 00:14:25.130 So why isn't that two way handshake sufficient? 00:14:26.120 --> 00:14:33.540 The reason this we need at least three packets so that both sides 00:14:33.890 --> 00:14:39.207 can be sure that the connection is to be established. 00:14:40.180 --> 00:14:43.050 Think about if we only had a two way handshake. 00:14:43.060 --> 00:14:47.020 So we only had this first packet here and a second packet here. 00:14:47.020 --> 00:14:51.460 Well there's no guarantee that that AC here from B to A 00:14:52.120 --> 00:14:57.310 actually arrives at , the AC could be lost inside the network. 00:14:57.310 --> 00:15:03.530 And so then we had the problem that A would treat the connection as... 00:15:03.530 --> 00:15:07.140 sorry, B would treat the connection as established. 00:15:07.210 --> 00:15:13.069 Assuming that the AC would arrive at A but A actually never receives the AC 00:15:13.540 --> 00:15:17.250 and A would treat the connection as not established 00:15:17.250 --> 00:15:19.260 because it hasn't received the AC 00:15:19.630 --> 00:15:23.243 So only view that third packet here going from A to B 00:15:23.653 --> 00:15:26.280 both A and B can be sure 00:15:26.620 --> 00:15:30.410 that the connection is in an established state. 00:15:30.420 --> 00:15:33.150 Second question down here is why do we have full message. 00:15:33.150 --> 00:15:34.950 Why do we have four messages here down 00:15:36.090 --> 00:15:39.170 rather than having only three messages. 00:15:39.240 --> 00:15:42.180 And again the four messages is not always happening. 00:15:42.180 --> 00:15:46.440 We may have three messages at times. 00:15:47.160 --> 00:15:53.080 But why have four messages in the extreme case, why is that? 00:15:53.080 --> 00:16:01.290 Well simple answer is that TCP actually supports half closed connections. 00:16:01.290 --> 00:16:06.020 So it supports the case where one side is closing 00:16:06.020 --> 00:16:10.130 its side of the connection but the other side still sending data 00:16:10.880 --> 00:16:15.680 and this only works with a four way sort of message tear down. 00:16:15.680 --> 00:16:20.960 So in this example, imagine for example that A wants to close 00:16:20.960 --> 00:16:24.140 because A does not have any data to send any more 00:16:24.140 --> 00:16:27.030 so A sends a FIN which is acknowledged by B with an AC 00:16:27.030 --> 00:16:29.520 but B actually still has data that needs to be sent to A 00:16:29.520 --> 00:16:34.234 so rather than sending this FIN immediately here 00:16:34.234 --> 00:16:38.680 B will continue sending data and then only when B has sent all the data 00:16:38.680 --> 00:16:42.300 it will close its end of the connection sending the FIN, 00:16:42.990 --> 00:16:48.231 and then that is acknowledged by the AC from A and then at that stage here, 00:16:48.360 --> 00:16:50.480 the connection is fully closed. 00:16:50.480 --> 00:16:53.580 So that the four message tear down allows us to do 00:16:54.270 --> 00:16:56.940 a half close on the connection basically 00:16:56.940 --> 00:17:02.809 or close one side and keep the other side open. 00:17:05.410 --> 00:17:10.780 There is a little activity on Cisco network and then a CAT here 00:17:10.780 --> 00:17:14.860 about TCP connection and termination process. 00:17:16.270 --> 00:17:18.950 I will quickly show you but I want you to do the whole activity 00:17:18.950 --> 00:17:23.390 I'll leave that for you as homework. 00:17:23.470 --> 00:17:25.030 Bear with me for a second. 00:17:26.590 --> 00:17:30.120 So here is the activity. 00:17:30.120 --> 00:17:33.510 The first activity is basically the three way handshake 00:17:33.510 --> 00:17:39.920 and you're meant to sort of drag those boxes over here 00:17:39.920 --> 00:17:42.090 into those fields here. 00:17:42.560 --> 00:17:47.490 Until that sort of process is correctly labeled. 00:17:47.840 --> 00:17:49.400 And so it's pretty trivial. 00:17:49.400 --> 00:17:51.880 So I mean A sends a SEE to B, right. 00:17:51.880 --> 00:17:57.360 So then what it means is that we have a SEE received here 00:17:57.360 --> 00:18:01.390 and we can check for correctness. 00:18:01.590 --> 00:18:03.770 So that's correct. 00:18:03.770 --> 00:18:08.130 And then you can basically drag and drop those other things over here 00:18:08.130 --> 00:18:10.320 up to here. 00:18:10.415 --> 00:18:15.155 Better learn how that handshake works, you better memorize it, 00:18:15.155 --> 00:18:19.237 and I think the other one, so the second part of the activity 00:18:19.237 --> 00:18:21.350 is about the termination session. 00:18:21.350 --> 00:18:26.346 So again there's two boxes here called FIN and AC 00:18:26.905 --> 00:18:30.748 and you'd have to sort of just drag those into those fields 00:18:30.748 --> 00:18:34.254 to describe the termination process. 00:18:36.700 --> 00:18:41.550 OK, let's go back to the lecture slides. 00:18:42.110 --> 00:18:47.650 So now I want to talk about the various sort of properties 00:18:47.650 --> 00:18:53.730 that TCP gives us or gives the application and TCP 00:18:53.730 --> 00:18:57.530 has quite a bit of functionality as you will see sort of. 00:18:57.560 --> 00:19:03.560 The first thing is that TCP provides in order, delivery of segments 00:19:03.560 --> 00:19:09.850 to the application and it does that based on sequence numbers. 00:19:09.860 --> 00:19:14.300 So what happens is that sender here 00:19:15.500 --> 00:19:17.750 divides that data up into the segments 00:19:18.170 --> 00:19:22.190 and the segments are numbered with sequence numbers 00:19:22.190 --> 00:19:27.730 so example from one to six and it sort of said in the first lecture 00:19:27.900 --> 00:19:30.330 an IP that works 00:19:30.330 --> 00:19:34.490 segments and packets that can take different parts through the network. 00:19:34.500 --> 00:19:37.820 So we'll have two possible routes here 00:19:37.820 --> 00:19:40.510 from the source to the destination some segments here, 00:19:40.510 --> 00:19:45.751 some segments or packets take this route, but others might take this route. 00:19:45.810 --> 00:19:48.460 So if they take different routes then 00:19:48.460 --> 00:19:52.260 they may actually arrive out of order at the destination. 00:19:52.260 --> 00:19:59.410 So in this case we receive segment 1, 2, 6 5, 4 and then 3 00:19:59.410 --> 00:20:02.670 so the orders obviously jumbled up. 00:20:02.670 --> 00:20:06.960 If we or the receiver here if the stuck at the receiver would pass up 00:20:07.260 --> 00:20:12.260 the segments in this jumbled up order then obviously you can imagine that 00:20:12.270 --> 00:20:16.730 the application but get a lot of garbage basically 00:20:16.730 --> 00:20:18.990 and couldn't interpret that data. 00:20:19.030 --> 00:20:21.960 So whatever you're doing like if you send an email 00:20:21.960 --> 00:20:23.990 this would be completely garbled up. 00:20:24.000 --> 00:20:28.560 So what TCP does is it reorders the segments 00:20:29.010 --> 00:20:32.559 back into the original order based on a sequence 00:20:32.559 --> 00:20:36.440 and as before it passes the segments to the application. 00:20:36.450 --> 00:20:40.250 So all the segments that are passed to the applications 00:20:40.250 --> 00:20:45.540 they are passed in the order they were sent by the sender. 00:20:45.810 --> 00:20:51.220 So there's no reordering on top of TCP 00:20:51.220 --> 00:20:54.700 or in other words applications that use TCP 00:20:54.700 --> 00:21:00.716 can be assured that segments or packets are not delivered... 00:21:01.326 --> 00:21:08.280 Not in the original order to the receiving application. 00:21:08.320 --> 00:21:13.198 The other thing TCP provides us with is reliable transport 00:21:13.198 --> 00:21:16.810 so the sequence numbers are used in conjunction with 00:21:16.930 --> 00:21:22.040 acknowledgement or Acs or acknowledgement numbers 00:21:22.040 --> 00:21:28.590 to provide reliable data transport so all the data transmitted 00:21:29.710 --> 00:21:37.160 using TCP must be acknowledged and an acknowledgement is cumulative. 00:21:37.180 --> 00:21:40.520 In TCP it means that it also acknowledges 00:21:40.520 --> 00:21:46.140 all the preceding segments that were received 00:21:46.140 --> 00:21:50.800 after the last acknowledgement that has been received. 00:21:50.800 --> 00:21:57.170 And receivers always acknowledge with the next expected badge. 00:21:57.250 --> 00:21:58.390 Keep that in mind. 00:21:58.510 --> 00:22:02.157 So if we look at the example over here we have a sender 00:22:02.157 --> 00:22:06.430 and we have a receiver and this example also 00:22:06.430 --> 00:22:09.250 introduces us to the concept of window size 00:22:09.250 --> 00:22:12.640 we'll come back to that on some of the following slides. 00:22:12.730 --> 00:22:17.620 So window is basically the amount of data that TCP can have in flight 00:22:17.650 --> 00:22:21.450 and acknowledge and so in this case it's 300 bytes. 00:22:21.460 --> 00:22:24.130 And so this is why the sender can send two 00:22:24.880 --> 00:22:28.370 1500 byte segments here over to the receiver. 00:22:28.370 --> 00:22:30.440 and the receiver receive those two 00:22:31.310 --> 00:22:33.830 and then the receiver will send an acknowledgement 00:22:34.340 --> 00:22:37.100 for both of these and you can see that the acknowledged number here 00:22:37.100 --> 00:22:41.240 is 3001, which is the next expected byte. 00:22:41.240 --> 00:22:44.260 So the receiver has received all the bytes for one to 3000. 00:22:44.270 --> 00:22:47.570 The next expected byte is 3001. 00:22:47.870 --> 00:22:51.260 Well when the sender gets acknowledgment the sender 00:22:51.260 --> 00:22:54.350 sort of sends more segments sends another two segments 00:22:54.350 --> 00:22:59.377 down here with the bytes 3001 to 6000 00:22:59.377 --> 00:23:02.880 and again the receiver will acknowledge. 00:23:03.020 --> 00:23:06.790 both of these segments here with one acknowledgement 00:23:06.790 --> 00:23:14.963 and it will have the number 6001 because that is the next byte 00:23:15.080 --> 00:23:22.840 the receiver expects the sender to send OK. 00:23:23.770 --> 00:23:29.950 Let's sort of go a bit more into the details here. 00:23:29.950 --> 00:23:35.860 So when segments are not acknowledged within the time limit 00:23:35.890 --> 00:23:38.530 so in the best case they are acknowledged 00:23:38.530 --> 00:23:42.155 like in a previous slide this is when everything goes perfectly fine 00:23:42.155 --> 00:23:46.186 but if things are not going that well and segments are not acknowledged 00:23:46.186 --> 00:23:50.759 within some time limit they need to be re-transmitted by the sender. 00:23:51.157 --> 00:23:54.616 Segments can be lost due to network congestion 00:23:54.888 --> 00:23:57.351 or interruptions to the medium. 00:23:57.620 --> 00:24:00.995 If somebody I don't know, takes out a cable or something like that 00:24:00.995 --> 00:24:04.670 or falls in the hardware of course. 00:24:04.670 --> 00:24:09.240 Data received after a loss is not acknowledged. 00:24:09.240 --> 00:24:13.950 This is illustrated in the figure over here. 00:24:13.950 --> 00:24:19.130 So here we have the case that everything was fine at the start 00:24:19.170 --> 00:24:23.680 but then when the sender sends two more segments here 00:24:23.680 --> 00:24:28.410 the first of those segments is actually lost because it's dropped 00:24:28.410 --> 00:24:32.190 somewhere in the network and it never arrives at the receiver. 00:24:32.200 --> 00:24:38.120 So then what the receiver will do is despite having received 00:24:38.120 --> 00:24:45.460 that later segment here covering the bytes between 4501 and 6000. 00:24:45.660 --> 00:24:52.460 Since TCP does not acknowledge bytes after loss 00:24:52.460 --> 00:24:58.760 it will send back another acknowledgement with the number 3001 00:24:59.360 --> 00:25:04.470 because that is the number up to at which point we've received 00:25:04.470 --> 00:25:10.170 you know, a continuous stream of segments and then we've lost a segment 00:25:10.170 --> 00:25:13.430 and we received another segment after that 00:25:13.430 --> 00:25:18.500 but we do not acknowledge any segments received after loss. 00:25:18.500 --> 00:25:24.467 We'll sort of acknowledge whatever we have received before the loss. 00:25:24.467 --> 00:25:30.660 Actually there is a mechanism to acknowledge segments 00:25:30.660 --> 00:25:32.640 received after a loss. 00:25:32.640 --> 00:25:37.544 It's called selective acknowledgements but it's out of the scope of the unit. 00:25:37.680 --> 00:25:42.990 So this is a bit more complicated than 00:25:43.050 --> 00:25:46.050 the simple sort of acknowledgement we discuss here 00:25:46.860 --> 00:25:50.460 and it's implemented to be much more efficient 00:25:51.810 --> 00:25:55.720 since of course what happens in this case here. 00:25:56.190 --> 00:26:01.500 Once the receiver acknowledges or it sends acknowledgement number 3001. 00:26:01.500 --> 00:26:08.000 Of course what happens is the sender will resend this segment here 00:26:09.150 --> 00:26:17.257 starting with byte 3001 as well as the next segment starting with byte 4001. 00:26:17.460 --> 00:26:19.890 So despite the fact that this segment the second here 00:26:19.890 --> 00:26:24.210 was already received with cumulative acknowledgements 00:26:24.210 --> 00:26:25.920 we'll have to resend 00:26:25.950 --> 00:26:29.550 or the sender has to resend this again as well. 00:26:29.550 --> 00:26:32.970 And so with selective ACs we can do this way more efficiently 00:26:32.970 --> 00:26:35.000 but it's also way more complicated. 00:26:35.070 --> 00:26:40.970 So it's out of scope of the discussion here. 00:26:41.110 --> 00:26:43.910 Next I want to talk about another feature of TCP 00:26:43.910 --> 00:26:47.970 which is called congestion control TTP uses congestion control 00:26:47.970 --> 00:26:50.920 to manage the rate of transmission. 00:26:50.920 --> 00:26:55.730 So you can think about it as an accelerator and brake 00:26:55.730 --> 00:27:01.630 on the rate of the transmission and the TCP congestion window 00:27:01.630 --> 00:27:04.340 specifies the maximum number of unacknowledged segments 00:27:04.340 --> 00:27:07.430 that can be in-flight from sender to receiver. 00:27:08.440 --> 00:27:11.760 Why do we actually have congestion control? 00:27:11.760 --> 00:27:15.350 Well let's do a little sort of thought experiment here. 00:27:15.550 --> 00:27:21.150 What if TCP senders could only send one packet at a time without AC 00:27:21.150 --> 00:27:24.160 If the round trip delay between the sender and receiver 00:27:24.160 --> 00:27:28.690 was something like two hundred milliseconds then you know it would mean 00:27:28.690 --> 00:27:32.190 that TCP could only send five packets per second. 00:27:32.240 --> 00:27:39.490 That would be very very slow . certainly we wouldn't congest 00:27:39.490 --> 00:27:44.470 the network but the TCP performance would be horribly slow. 00:27:44.470 --> 00:27:49.370 So what if on the other hand TCPs senders could sent 00:27:49.370 --> 00:27:53.830 as fast as a LAN connection permits for example of one gigabit per second. 00:27:54.130 --> 00:27:57.940 Well the gateway to the Internet is usually a bottleneck, 00:27:57.940 --> 00:28:00.240 and the gateway to the Internet, 00:28:00.250 --> 00:28:05.838 If you think about home networks for example it's unlikely to be able 00:28:05.838 --> 00:28:09.550 to send with one gigabits per second into the Internet. 00:28:09.580 --> 00:28:14.720 So then we get what is called congestion on the gateway. 00:28:14.740 --> 00:28:20.980 So packets are building up in the queues and eventually we have 00:28:22.030 --> 00:28:29.850 full queues and any further packets arriving will be dropped. 00:28:30.280 --> 00:28:36.000 And you also need to consider that we share the resources 00:28:36.530 --> 00:28:39.740 we share the network with many many other users. 00:28:40.020 --> 00:28:45.803 So it's just a little picture here to illustrate the links 00:28:45.803 --> 00:28:49.672 that carry traffic between different continents, 00:28:49.856 --> 00:28:52.996 and you can see there's quite a number of links between 00:28:52.996 --> 00:28:56.207 United States and Asia, and United States with Europe. 00:28:56.540 --> 00:29:01.324 But it's not that many links connecting Australia to the rest of the world. 00:29:01.700 --> 00:29:06.927 So these are usually fiber links and you can imagine that 00:29:06.927 --> 00:29:10.970 those links you know that carry the traffic of, 00:29:11.490 --> 00:29:14.690 of billions or tens or hundreds of millions 00:29:14.690 --> 00:29:16.920 of concurrent TCP connections. 00:29:17.270 --> 00:29:22.460 So all of these TCP connections share the links 00:29:23.330 --> 00:29:28.930 and so the question is how does a TCP sender 00:29:29.050 --> 00:29:35.270 find that the perfect rate, so that fair share of a 100% 00:29:35.270 --> 00:29:40.532 utilized bottleneck link speed. 00:29:43.970 --> 00:29:49.130 So finding that you know that perfect weight where we sort of 00:29:49.340 --> 00:29:54.570 fairly share that think with lots and lots of other TCP connections. 00:29:54.570 --> 00:29:59.280 At the same time we'll utilize all the bandwidth or the capacity 00:29:59.280 --> 00:30:06.760 that it has while at the same time we'll try to avoid congestion in routers. 00:30:06.830 --> 00:30:12.570 Well that is the job of the congestion control algorithm inside TCP. 00:30:13.070 --> 00:30:16.870 And there are many congestion control algorithms. 00:30:16.900 --> 00:30:23.241 And on this slide also want to briefly illustrate the new redo algorithm. 00:30:23.410 --> 00:30:26.470 It's one of the traditional algorithms that was 00:30:26.470 --> 00:30:31.720 the default algorithm for a long time in most operating systems. 00:30:31.720 --> 00:30:35.560 So that algorithm has two phases and has a slow start phase 00:30:35.560 --> 00:30:42.229 and there's a congestion avoidance phase and a slow start is actually not that slow 00:30:42.229 --> 00:30:44.617 despite the fact that it's named slow start. 00:30:44.710 --> 00:30:49.080 So what slow start as is or what TCP does 00:30:49.080 --> 00:30:52.010 Slow start is it starts with an initial. 00:30:52.010 --> 00:30:57.833 Congestion window of two segments or these days will actually use 10 segments, 00:30:58.540 --> 00:31:00.910 as the initial congestion window. 00:31:00.910 --> 00:31:04.243 And then the sender will increase the congestion window by one segment 00:31:04.243 --> 00:31:06.966 for every packet acknowledged by the receiver. 00:31:07.390 --> 00:31:12.270 So this will lead to a relatively quick increase in throughput 00:31:12.270 --> 00:31:16.440 up to the maximum possible fare share. 00:31:16.440 --> 00:31:20.210 By the time when the sender detects packet loss. 00:31:20.470 --> 00:31:27.070 It halves the window and then it goes into congestion avoidance 00:31:27.390 --> 00:31:33.120 In the and avoidance phase without loss, 00:31:33.120 --> 00:31:38.120 the window is increased by one segment for each round trip time. 00:31:38.120 --> 00:31:44.374 Round trip time means the time it takes for a packet to go from A to B 00:31:44.460 --> 00:31:47.190 and a response to come back from B to A. 00:31:47.220 --> 00:31:50.330 So that's that's a road trip that's a round trip time. 00:31:50.330 --> 00:31:53.520 So for each round trip sender will increase the window by one segment 00:31:54.120 --> 00:32:01.790 when the sender transmits to fast and congests the link again, 00:32:01.800 --> 00:32:05.790 then it will mean that you know a congestion at the router occurs, 00:32:06.650 --> 00:32:10.250 queues also, and there will be packet drops. 00:32:10.250 --> 00:32:15.420 When the sender detects those packet drops it has its window 00:32:16.160 --> 00:32:20.530 So this quickly shrinking off the window will quickly reduce 00:32:20.530 --> 00:32:24.690 the throughput of the connection but it will also quickly reduce 00:32:24.780 --> 00:32:27.020 the congestion on the bottleneck. 00:32:27.140 --> 00:32:28.360 That's the idea. 00:32:28.950 --> 00:32:33.380 And then after that we'll have that sort of slow increase 00:32:33.380 --> 00:32:36.359 in one segment each round trip time again. 00:32:36.580 --> 00:32:40.370 Where the sort of sender starts basically sending more and more 00:32:40.370 --> 00:32:42.745 until we sort of hit the limit again. 00:32:42.970 --> 00:32:50.339 And to a sort of to better illustrate that it's easiest to see this in a graph. 00:32:50.380 --> 00:32:52.530 This is an actual graph of the congestion window 00:32:52.540 --> 00:32:57.250 of a single TCP connection going through a bottleneck 00:32:57.250 --> 00:32:59.470 and you can see at the start here, 00:32:59.480 --> 00:33:03.630 slow start where we have a rapid increase of the congestion window 00:33:03.630 --> 00:33:07.990 and then we have the first packet loss and congestion we know sort of drops, 00:33:08.020 --> 00:33:12.920 halved, it's halved again and then we go into congestion avoidanc 00:33:12.920 --> 00:33:14.947 and you can see us saw tooth pattern 00:33:14.947 --> 00:33:17.710 and congestion avoidance will basically... 00:33:18.040 --> 00:33:22.900 Will slowly increase the congestion window over time, 00:33:22.900 --> 00:33:26.571 but when it's one to time and then at some stage 00:33:26.571 --> 00:33:28.930 we'll hit congestion again if there's packet loss, 00:33:28.930 --> 00:33:31.120 will quickly or the sender will quickly 00:33:31.660 --> 00:33:35.290 reduce the window to half of its size 00:33:35.950 --> 00:33:38.980 and then we'll start the upward probing again 00:33:39.070 --> 00:33:42.610 until we hit loss again half a window and so on. 00:33:42.610 --> 00:33:45.950 So with a single flow through a bottleneck we get to see 00:33:45.970 --> 00:33:49.480 a perfect saw tooth pattern of course with multiple flows. 00:33:49.480 --> 00:33:59.090 This will look much messier so to come back to the point of congestion 00:33:59.090 --> 00:34:02.320 of congestion again so make it very clear what it means is 00:34:02.750 --> 00:34:05.400 so congestion occurs when the number of packets arriving 00:34:05.400 --> 00:34:10.480 at a router is higher than number of ACs that can be sent on the next link. 00:34:10.520 --> 00:34:14.280 So if we have lots of different devices here, 00:34:14.280 --> 00:34:17.640 all send packets to the router then sent to the Internet. 00:34:17.960 --> 00:34:21.050 And this is the one link to the Internet, let's say, 00:34:21.080 --> 00:34:29.314 and the link speed here of this link is less than the combined link speeds 00:34:29.690 --> 00:34:32.610 for all these different devices then. 00:34:32.960 --> 00:34:36.740 Well we have to buffer packets on the router 00:34:37.450 --> 00:34:42.200 if the packet rates are too high or higher than this link, right? 00:34:42.650 --> 00:34:47.720 And if those rates are persistently higher then this link 00:34:47.720 --> 00:34:52.130 will then of course eventually will get filled with all of our buffers. 00:34:52.430 --> 00:34:56.014 And then the router has no choice but to drop packets. 00:34:57.610 --> 00:35:03.946 And then of course with TCP congestion control we have the fact that 00:35:04.160 --> 00:35:08.710 the TCP under senders here will take that bus 00:35:08.710 --> 00:35:10.680 as indication for congestion. 00:35:10.880 --> 00:35:14.950 The window will be halved and all of those devices here 00:35:14.950 --> 00:35:17.150 will send a lot less packets. 00:35:17.150 --> 00:35:21.658 Which then means the queues, they can be drained, 00:35:21.860 --> 00:35:26.090 and we won't have any loss sort of in there (INAUDIBLE) 00:35:26.120 --> 00:35:30.640 but again the window size will increase again. 00:35:30.640 --> 00:35:36.990 All those devices there was some sense of faster and faster rates 00:35:36.990 --> 00:35:40.680 based on the upward probing of the congestion control algorithm 00:35:40.680 --> 00:35:45.499 until the queues become full again and we'll have the next packet loss, 00:35:45.499 --> 00:35:49.400 and then we'll send less again and so on. 00:35:50.630 --> 00:35:54.750 Now you might say okay well if the problem is packet loss 00:35:54.750 --> 00:35:59.529 if packets are full then why not make the router buffers really really big. NOTE Paragraph 00:36:00.180 --> 00:36:04.020 So we can basically avoid any any packet losses 00:36:04.020 --> 00:36:07.780 so we can have a case where either the combined sender rates 00:36:07.780 --> 00:36:09.030 can be higher than that 00:36:09.030 --> 00:36:12.180 then you communicate for a very very long time. 00:36:12.620 --> 00:36:16.640 If we have big buffers you can have it sort of 00:36:16.650 --> 00:36:18.860 for varying something like packet drops. 00:36:19.170 --> 00:36:23.721 And this is what quite a number of people actually used to think for years 00:36:23.721 --> 00:36:28.570 and it led to a fairly large buffers which caused another problem though 00:36:28.570 --> 00:36:31.320 which is referred to as buffered load. 00:36:32.140 --> 00:36:38.335 If buffer sizes are very large then that means also the latency 00:36:38.335 --> 00:36:42.370 will be quite high because packets are stuck in those buffers 00:36:42.370 --> 00:36:43.910 for quite some time. 00:36:44.010 --> 00:36:47.680 And so remember your email will always eventually fill the buffers 00:36:47.680 --> 00:36:53.196 to full capacity and those large buffers will take a long time to clear. 00:36:53.872 --> 00:36:59.580 Any applications that require reliability but also really benefit 00:36:59.580 --> 00:37:03.990 from low latency that say stock trading for example. 00:37:03.990 --> 00:37:06.900 They have an issue with the high latency 00:37:07.440 --> 00:37:10.270 that's caused by this buffered load 00:37:10.470 --> 00:37:18.318 so buffers have to be reasonably small to maintain a reasonably low network latency. 00:37:18.600 --> 00:37:22.655 So we can't just make buffers really really big that will cause problems 00:37:22.710 --> 00:37:32.821 for applications that you know rely on or benefit from lower latency. 00:37:33.580 --> 00:37:37.200 So we talked about (INAUDIBLE) which has been 00:37:37.200 --> 00:37:41.550 the standard congestion control mechanism for some time. 00:37:42.070 --> 00:37:43.950 It's still used by Windows. 00:37:44.230 --> 00:37:47.350 It was still used by Mac OS until fairly recently. 00:37:47.920 --> 00:37:51.070 But actually dozens perhaps hundreds 00:37:51.070 --> 00:37:57.950 including sort of research research kind of algorithms 00:37:57.950 --> 00:38:00.510 that exist, Linux and Mac OS 00:38:00.550 --> 00:38:03.000 now use a different algorithm called cubic. 00:38:03.160 --> 00:38:06.057 And there's also an algorithm called BBR, it's been designed by Google 00:38:06.057 --> 00:38:10.256 in recent years, it has created a bit of a hype 00:38:10.590 --> 00:38:13.000 Not all aim for maximum performance. 00:38:13.260 --> 00:38:18.450 So some might have slightly different aims and there's also algorithms 00:38:18.480 --> 00:38:22.590 that use estimates of network delay as an indicator of congestion as well 00:38:22.590 --> 00:38:25.050 not just losses indicate of congestion 00:38:25.080 --> 00:38:28.610 but also estimates of network like for example BBR. 00:38:29.070 --> 00:38:33.930 And despite the fact that TCP is a fairly old protocol 00:38:34.760 --> 00:38:37.620 TCP congestion control is still a highly active 00:38:37.620 --> 00:38:40.770 research area in data communications. 00:38:42.480 --> 00:38:48.220 There's also something called active queue management. 00:38:48.220 --> 00:38:57.040 So the idea is to improve things by actually routers actively telling 00:38:57.040 --> 00:39:05.000 TTP senders that there is congestion sort of if routers could tell senders 00:39:05.130 --> 00:39:09.590 and sort of some configure buffer that is when there's congestion then, 00:39:09.590 --> 00:39:17.360 senders could back off earlier and we could avoid the packet loss. 00:39:17.470 --> 00:39:20.930 So there are some algorithm of active queue management 00:39:21.080 --> 00:39:24.480 and there is something called TCP early congestion notification. 00:39:24.890 --> 00:39:28.930 And the idea is that the route of the mock packets when the queue length 00:39:28.930 --> 00:39:32.010 or the estimate layers above computable threshold. 00:39:32.450 --> 00:39:35.180 And then the TTP receiver will echo those marks 00:39:35.180 --> 00:39:38.640 back to the sender and the sender can reduce 00:39:38.640 --> 00:39:42.500 the congestion window before we actually get to that stage 00:39:42.500 --> 00:39:44.000 where we have packet loss. 00:39:44.030 --> 00:39:47.930 So using this mechanism will actually improve performance. 00:39:49.470 --> 00:39:56.240 But it requires that routers support this mechanism. 00:39:56.280 --> 00:40:01.680 And of course senders and receivers must also support the mechanism 00:40:04.483 --> 00:40:08.800 Active queue management can actually improve performance quite a bit 00:40:08.800 --> 00:40:12.610 but many people don't actually notice. 00:40:12.640 --> 00:40:16.030 So to illustrate that point, I created this little slide here. 00:40:16.030 --> 00:40:22.650 So we have the normal sort of FIFO queues 00:40:22.690 --> 00:40:25.856 and also two graphs appear for FIFO queues 00:40:26.260 --> 00:40:28.450 first in first out and then down here, 00:40:28.450 --> 00:40:32.860 those two graphs are for an active queue management mechanism. 00:40:32.860 --> 00:40:35.370 called F Queue codal. 00:40:35.720 --> 00:40:38.000 This is from an experiment where we have... 00:40:38.850 --> 00:40:42.110 when we look at the UpLink let's say 00:40:42.410 --> 00:40:45.560 the uplink from your home network to the Internet 00:40:45.560 --> 00:40:48.000 and there's three traffic flows. 00:40:48.020 --> 00:40:51.610 There is a gaming flow based on UDP going upstream. 00:40:51.620 --> 00:40:56.670 That's the dark blue line here so those two graphs are throughput graphs, 00:40:56.670 --> 00:41:00.950 so just write the throughput of the three different traffic flows 00:41:00.950 --> 00:41:05.300 so that flow here is a game traffic it's veryy constant sort of throughput 00:41:05.300 --> 00:41:11.560 and the other two traffic flows are TCP connections. 00:41:11.650 --> 00:41:16.049 So the light brown here, that's the throughput of the TCP connections. 00:41:16.049 --> 00:41:18.540 And those two graphs in the right hand side here 00:41:18.540 --> 00:41:24.550 show the RTT that those traffic flows experience. 00:41:24.900 --> 00:41:30.390 And the sort of fixed delay for this experiment 00:41:30.390 --> 00:41:36.160 was set to 100 milliseconds of RTT and anything above 00:41:36.170 --> 00:41:39.970 100 milliseconds is added, constitutes delay added by 00:41:39.970 --> 00:41:44.590 queueing the packets inside the router and so you can see 00:41:44.590 --> 00:41:48.880 with our traditional sort of first in first out strategy 00:41:48.880 --> 00:41:52.360 we'll get fairly high delays and like all 00:41:52.370 --> 00:41:54.560 the three different traffic flows experienced 00:41:54.560 --> 00:41:57.830 the same types of delays and the like it's fairly high, 00:41:57.830 --> 00:42:00.637 so we almost reached 300 milliseconds here 00:42:01.190 --> 00:42:04.860 much much higher than the sort of the base delay. 00:42:05.840 --> 00:42:11.150 So when we do the same type of experiments but with F Queue codal 00:42:11.150 --> 00:42:15.740 to manage the queue then A you see in the throughput graph here, 00:42:15.740 --> 00:42:21.190 we got a bit of more fairness in the sharing here I suppose 00:42:21.190 --> 00:42:25.580 of the TCP flows closer to the fair share 00:42:25.580 --> 00:42:29.200 whereas here, that's a fair bit of going up and down. 00:42:29.630 --> 00:42:34.220 And the other thing you can see while one thing is quite hard to see 00:42:34.220 --> 00:42:37.730 but for the actual game traffic here the delay is really minimal. 00:42:37.730 --> 00:42:40.970 So the dark blue dots they only extend up to here. 00:42:41.010 --> 00:42:46.910 OK so we'll barely reach 125 milliseconds for the game traffic 00:42:46.910 --> 00:42:50.440 which is of course very important if you play first person shooter games 00:42:50.440 --> 00:42:58.490 and for the TCP flows we get a little bit more delay here but basically after that 00:42:58.500 --> 00:43:00.950 so slow start fair, well, we'll never really exceed 00:43:01.030 --> 00:43:08.088 200 milliseconds of delay so you can see the positive effect here 00:43:08.088 --> 00:43:12.650 will reduce delay and we'll get a fairer sharing here 00:43:13.190 --> 00:43:17.705 and that's actually home routers where you can you can turn this on 00:43:17.705 --> 00:43:21.810 so you can actually change from FIFO to F Queue codal. 00:43:21.880 --> 00:43:27.590 so this is usually this usually behind some 00:43:27.590 --> 00:43:30.060 of the quality of of service settings that 00:43:30.140 --> 00:43:32.030 you can do with your routers here. 00:43:32.330 --> 00:43:34.708 You can investigate and see if your router supports it 00:43:34.708 --> 00:43:37.358 and you might actually get better quality of service 00:43:37.358 --> 00:43:40.799 by turning those mechanisms on. 00:43:42.280 --> 00:43:45.370 Another mechanism that TCP has is CCP flow control 00:43:46.240 --> 00:43:48.640 it's very similar to congestion control but it's 00:43:49.420 --> 00:43:51.850 to prevent the sender from overflowing the receiver 00:43:52.420 --> 00:43:54.970 instead of offering that at the network bottleneck. 00:43:55.900 --> 00:44:00.550 So I think at the sender receiver having vastly different performance 00:44:00.550 --> 00:44:06.190 for example a Netflix cache with a low cost smart TV. 00:44:06.190 --> 00:44:09.430 The way it works is the receiver advertise the receive window 00:44:09.430 --> 00:44:13.080 the number of bytes it will accept before the next acknowledgement 00:44:13.080 --> 00:44:14.830 or window update. 00:44:15.230 --> 00:44:18.560 And then this is based on the windowing mechanism 00:44:19.100 --> 00:44:20.900 much like congestion control 00:44:20.900 --> 00:44:24.380 and overall the sender will be restricted to the minimum 00:44:24.950 --> 00:44:27.715 of the congestion window and the receive window of course 00:44:27.940 --> 00:44:31.340 So that's why we're basically trying to avoid 00:44:32.030 --> 00:44:36.360 the network bottleneck and the receiver. 00:44:36.500 --> 00:44:40.400 Alright and that's the basic data about the TCP protocol. 00:44:40.400 --> 00:44:45.860 Also the next couple of slides will discuss the other 00:44:45.860 --> 00:44:50.140 major transport protocol the UDP datagrams protocol and... 00:44:50.300 --> 00:44:54.140 Well as you will see here UDP is much simpler. 00:44:54.140 --> 00:44:58.420 So UDP is used when the data must arrive in a timely manner 00:44:58.420 --> 00:45:02.441 unlike TCP, UDP is connectionless protocol. 00:45:02.470 --> 00:45:05.960 So there's no connection set up, connection tear down, 00:45:06.000 --> 00:45:09.510 There's no notion of a connection with UDP. 00:45:09.520 --> 00:45:15.640 It's a best effort protocol and has no equivalent to TCP acknowledgement. 00:45:15.780 --> 00:45:19.530 So it's not necessarily less reliable but there's 00:45:19.530 --> 00:45:25.530 no reliability built in, there's no reliability guaranteed. 00:45:25.590 --> 00:45:29.700 If there is packet loss then UDP datagrams 00:45:29.700 --> 00:45:35.280 they're just lost and there's no re transmitting mechanism. 00:45:35.280 --> 00:45:40.530 Also if datagrams are reordered in the network at the receiver 00:45:40.530 --> 00:45:45.140 there's no attempt to reorder those datagrams back into the original order. 00:45:45.210 --> 00:45:48.013 It also has no congestion or flow control 00:45:48.760 --> 00:45:53.308 but on the positive side with UDP we very low pay packet overhead 00:45:53.308 --> 00:45:57.750 so you have a much smaller and simpler packet header. 00:45:58.000 --> 00:46:02.229 The one thing that UDP has in common with TCP, is port number. 00:46:02.229 --> 00:46:07.390 So UDP has exactly the same sort of port numbers 00:46:07.390 --> 00:46:11.308 that TCP has, so same thing and then you will see 00:46:11.308 --> 00:46:15.270 it's got the same port number, fields and header as I'll show you that 00:46:15.270 --> 00:46:17.800 in aslide or two. 00:46:17.800 --> 00:46:20.890 So yeah, to stress the point about UDP right. 00:46:20.890 --> 00:46:24.630 Reliability or lack thereof. 00:46:24.700 --> 00:46:28.970 So UDP will not reassemble data packets to the original order 00:46:28.970 --> 00:46:33.700 and it will not resend lost datagrams because it's connection is unreliable. 00:46:33.700 --> 00:46:37.630 So this is sort of the same that we looked at before 00:46:37.630 --> 00:46:41.260 with TCP where datagrams can take different 00:46:41.650 --> 00:46:46.000 paths through the network and with UDP if the order 00:46:46.000 --> 00:46:48.250 is jumbled up because of its different parts. 00:46:48.250 --> 00:46:52.450 Well then the datagrams will be delivered in this jumbled up order 00:46:52.450 --> 00:46:59.009 to the application and then the application has to sort that issue out. 00:46:59.590 --> 00:47:01.660 So why would an application actually use 00:47:01.660 --> 00:47:04.810 this kind of unreliable transport protocol. 00:47:04.810 --> 00:47:07.371 Well there's a couple of cases where 00:47:07.371 --> 00:47:11.440 we prefer UDP over TCP. And the first case is because 00:47:11.770 --> 00:47:16.700 resending data is useless and we want to avoid any additional delay. 00:47:16.700 --> 00:47:19.580 So if you think about teleconferencing 00:47:19.580 --> 00:47:26.740 something like Skype or Discord or whatever additional delay 00:47:26.740 --> 00:47:30.130 for re transmissions are more annoying than 00:47:30.130 --> 00:47:34.150 the drop outs in the voice similar online games. 00:47:34.150 --> 00:47:37.330 There's no point in resending packets after some actions 00:47:37.930 --> 00:47:42.730 because you don't really want a lag game. 00:47:42.740 --> 00:47:47.592 So you'd rather take into account that there maybe packet loss 00:47:47.592 --> 00:47:51.520 and for example use some redundancy. 00:47:51.680 --> 00:47:56.980 That's what many games use, so send data across multiple packets 00:47:56.980 --> 00:47:59.420 so it doesn't matter if one is lost. 00:47:59.420 --> 00:48:02.330 But we don't add any extra delay because 00:48:02.730 --> 00:48:06.508 on games that might be quite delay sensitive 00:48:06.508 --> 00:48:11.421 if you think about first person shooter games or similar games. 00:48:11.690 --> 00:48:17.230 So that's one reason we want to keep the delay sort of 00:48:17.320 --> 00:48:23.094 really short and we don't need to recent data. 00:48:24.050 --> 00:48:30.860 Second case is we want to avoid the complexities of TCP 00:48:30.860 --> 00:48:33.730 and the omits of TCP. 00:48:33.730 --> 00:48:38.350 So a full TCP implementation is very complex and it may 00:48:38.350 --> 00:48:42.760 be too complex for this human based LCP or the RAM. 00:48:44.010 --> 00:48:49.700 And the application can implement a simple acknowledgement scheme 00:48:49.700 --> 00:48:53.180 on top of UDP to transport the item that's required. 00:48:53.690 --> 00:48:57.750 An example of such a protocols, it should be your file transfer protocols. 00:48:57.750 --> 00:48:58.500 the FTP. 00:48:59.330 --> 00:49:06.890 It's basically a simple sort of reliable protocol that sits on top of UDP. 00:49:06.920 --> 00:49:11.978 but it's simpler than a full TCP implementation 00:49:14.590 --> 00:49:18.940 And the third case where you might want to use UDP 00:49:18.940 --> 00:49:22.775 is because you want to avoid the setup and the tear down. 00:49:22.775 --> 00:49:27.250 of connections that we have in TCP 00:49:27.250 --> 00:49:29.830 because setting up and tearing down TCP connections 00:49:29.830 --> 00:49:32.180 requires a minimum of six packets. 00:49:32.180 --> 00:49:37.810 OK that's a fair bit of sort of bandwidth, it might be unnecessary 00:49:37.890 --> 00:49:45.087 and also setting up connections requires the server to be in state of connections 00:49:45.150 --> 00:49:51.790 so that uses view CPU and also RAM and you want to avoid that 00:49:51.790 --> 00:49:57.290 If we have frequent so short message exchanges 00:49:57.290 --> 00:50:00.768 it's actually more efficient and cheaper in terms of bandwidth. 00:50:00.768 --> 00:50:06.000 So resources to use UDP and a prime example of this is DNS lookups. 00:50:07.530 --> 00:50:09.850 So with DNS we have serverss that have to deal 00:50:09.850 --> 00:50:13.020 with thousands of requests per second. 00:50:13.020 --> 00:50:16.460 And the DNS requests plus replies usually only two packets 00:50:16.460 --> 00:50:21.153 so one packet for the request and then there's one packet for the reply 00:50:21.180 --> 00:50:26.330 and that's a quarter of the packets that we would need with TCP 00:50:26.340 --> 00:50:30.450 So remember we'll not only have those two packets but an additional 00:50:30.450 --> 00:50:34.640 six packets for setting up a connection and then tearing it down. 00:50:34.800 --> 00:50:38.968 Plus if we have those short message exchanges then flow congestion 00:50:39.080 --> 00:50:42.113 so flow control and congestion control 00:50:42.150 --> 00:50:43.980 they're really useless for these short flows 00:50:43.980 --> 00:50:45.990 I mean that that they don't work. 00:50:45.990 --> 00:50:50.290 They only work for so longer term flows. 00:50:50.500 --> 00:50:55.290 And well last but not least if you use UDP we can actually implement 00:50:55.310 --> 00:51:00.210 a reliable transport protocol on top of UDP without having to change 00:51:00.690 --> 00:51:06.810 the operating system kernel because remember the protocols stack up to 00:51:06.810 --> 00:51:10.650 the transport layer actually implemented in the operating system kernel. 00:51:11.430 --> 00:51:16.140 And it's harder to make changes there and it's impossible 00:51:16.590 --> 00:51:20.790 if the operating system is closed source so for example like Mac OS and windows. 00:51:20.790 --> 00:51:25.200 So there is a protocol called Quick. It's a new transport protocol, 00:51:25.200 --> 00:51:26.880 it'ss developed at Google to optimise 00:51:27.480 --> 00:51:31.590 HTTP performance and to you most likely use it 00:51:31.590 --> 00:51:35.310 every day if you actually use the Chrome browser. 00:51:35.460 --> 00:51:39.120 And so the problem for Google was they wanted to do 00:51:40.160 --> 00:51:46.400 an improved protocol to improve performance but pushing Quick 00:51:46.400 --> 00:51:50.070 into the operating system kernels of all sorts of 00:51:51.210 --> 00:51:57.390 clients that would be very difficult for Google to do. 00:51:57.720 --> 00:52:02.010 But they own the Chrome browser so they can very easily 00:52:02.010 --> 00:52:06.480 implement a transport protocol on top of UDP inside the browser. 00:52:06.480 --> 00:52:11.504 So that's why they chose that avenue of course in terms of resources 00:52:11.504 --> 00:52:13.830 the implementation inside the browser might 00:52:14.070 --> 00:52:19.360 take up a few more cycles in terms of CPU. 00:52:19.570 --> 00:52:22.840 But the good thing for Google is they fully control that 00:52:22.840 --> 00:52:25.750 environment that can push updates at any point in time 00:52:26.410 --> 00:52:29.380 and they just have to update chrome rather than having to 00:52:29.380 --> 00:52:34.840 update lots and lots of different operating systems. 00:52:34.840 --> 00:52:39.490 Almost at the end so just have a quick look at the UDP and TCP protocol 00:52:39.490 --> 00:52:42.910 headers here so you can see that the TTP protocol header 00:52:42.910 --> 00:52:45.450 is much bigger obviously because we have much 00:52:45.450 --> 00:52:49.500 more functionality in TCP and the UDP head down here. 00:52:49.920 --> 00:52:54.180 You can see that both headers have the source port 00:52:54.240 --> 00:52:59.240 and the destination port as the first two header fields and then 00:52:59.240 --> 00:53:04.170 the UDP hasn't got much else besides the length and the checksum 00:53:05.020 --> 00:53:07.570 but TCP of course we have the sequence numbers. 00:53:07.590 --> 00:53:12.510 We have the acknowledgement numbers we have the window size 00:53:12.510 --> 00:53:17.520 and a bunch of flex to deal with all the threeway handshake 00:53:17.520 --> 00:53:20.990 tear downs and so on. 00:53:20.990 --> 00:53:25.780 So let's discuss TCP by this UDP. 00:53:25.810 --> 00:53:28.070 Well neither protocol is better. 00:53:28.090 --> 00:53:31.180 It's just what's appropriate for the application. 00:53:32.170 --> 00:53:37.259 So if you're an application developer you must decide what to use. 00:53:40.949 --> 00:53:45.614 If your application, you know, requires fast protocol, low overheads, 00:53:45.640 --> 00:53:48.720 you don't need acknowledgments you don't need to reset lost data 00:53:48.720 --> 00:53:51.850 and you want to deliver data as fast as it arrives 00:53:51.850 --> 00:53:54.340 for example for things like IP tuner 00:53:54.340 --> 00:53:58.280 for streaming rather than UDP is your choice. 00:53:58.350 --> 00:54:04.960 If you need reliability you'd acknowledgements reending of those data 00:54:04.960 --> 00:54:07.630 and data needs to be delivered to the application. 00:54:07.650 --> 00:54:11.400 in the order it was sent which is the case for example 00:54:11.400 --> 00:54:13.750 for applications like email or web. 00:54:13.800 --> 00:54:22.050 Then you should use TCP of course. A little a homework for you 00:54:22.050 --> 00:54:29.111 the following Cisco or network activity let me just quickly switch to that. 00:54:29.170 --> 00:54:40.820 So it's basically activity to select 00:54:40.820 --> 00:54:45.550 the right transport protocol for a number of different applications. 00:54:45.550 --> 00:54:49.170 So over here have all those applications HDP 00:54:49.240 --> 00:54:54.000 telnet FTP and we all discussed a couple of those in the first lecture 00:54:54.000 --> 00:54:58.990 and you basically have to drag those boxes over here 00:54:58.990 --> 00:55:04.230 to indicate where the something is either TCP or UDP or both. 00:55:04.660 --> 00:55:07.100 So one example HDP. 00:55:07.440 --> 00:55:09.520 We discussed that uses TCP, right. 00:55:09.520 --> 00:55:11.470 And you can check your answers. That's correct. 00:55:13.180 --> 00:55:19.540 Well I'll leave the rest for you to do at home. 00:55:19.550 --> 00:55:25.750 And I will conclude lecture as much of lecture objectives 00:55:25.750 --> 00:55:31.490 and you should be able to describe a number of things 00:55:31.490 --> 00:55:34.432 I won't go through all these lecture objectives in detail 00:55:34.432 --> 00:55:39.240 so just read all of those and make sure you understand 00:55:39.240 --> 00:55:44.380 all those concepts and you can describe those concepts then... 00:55:45.040 --> 00:55:47.920 Well today's lecture we looked at the application presentation, 00:55:47.920 --> 00:55:53.560 such layers and the two major architect socommunications. 00:55:53.560 --> 00:55:57.050 And we also looked at the transport layer 00:55:57.050 --> 00:56:01.495 and the two main transport layer protocols, TCP and UDP. 00:56:01.500 --> 00:56:07.470 The readings for this week introduction to the chapters 9 and 10. 00:56:07.480 --> 00:56:11.010 And don't forget participation quiz. 00:56:11.170 --> 00:56:18.400 One is to this Sunday and in the lapse in the second week 00:56:18.400 --> 00:56:22.110 we'll examining some network traffic using a tool called Bioshock 00:56:22.180 --> 00:56:27.420 so we look at actual DNS packets and it's a three way handshake 00:56:27.420 --> 00:56:32.350 and how those things actually look on the web. 00:56:32.620 --> 00:56:38.760 Oh well we'll look at those things flash up. 00:56:38.760 --> 00:56:44.670 And then the next week we will continue descending down the old same model. 00:56:44.880 --> 00:56:48.690 And so we'll talk about the network LAN next week. 00:56:48.690 --> 00:56:53.720 Specifically you'll look at IP addressing and something called subnetting 00:56:54.720 --> 00:57:00.239 And we will start discussing the role of routers in data communications. 00:57:01.830 --> 00:57:06.600 Well this is an online lecture so you don't really sort of 00:57:06.600 --> 00:57:09.630 bring pen and paper because I assume you probably 00:57:09.630 --> 00:57:12.540 have a pen and paper wherever you're watching this lecture 00:57:12.580 --> 00:57:16.890 but you have some pen and paper ready for exercise. 00:57:17.850 --> 00:57:19.650 That's it for me for this week. 00:57:19.650 --> 00:57:21.500 I'll see you next week's lecture.