[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:04.85,0:00:09.75,Default,,0000,0000,0000,,SPEAKER: Hello and welcome back \Nto the second part of lecture 2
Dialogue: 0,0:00:09.75,0:00:13.37,Default,,0000,0000,0000,,which is about the transport layer.
Dialogue: 0,0:00:13.91,0:00:20.56,Default,,0000,0000,0000,,The transport layer segments application \Ndata into transportable chunks
Dialogue: 0,0:00:20.56,0:00:27.33,Default,,0000,0000,0000,,for transmission and also reassembles\Nsegments as required
Dialogue: 0,0:00:27.33,0:00:34.93,Default,,0000,0000,0000,,on the receiver side \Nthe transport layer uses port numbers.
Dialogue: 0,0:00:34.98,0:00:40.33,Default,,0000,0000,0000,,We also refer to those as ports\Nfor short
Dialogue: 0,0:00:40.33,0:00:46.35,Default,,0000,0000,0000,,to track individual \Nconversations and identify applications.
Dialogue: 0,0:00:46.41,0:00:52.19,Default,,0000,0000,0000,,It is important to not confuse \Nthese port numbers or ports
Dialogue: 0,0:00:52.19,0:00:57.26,Default,,0000,0000,0000,,with physical ports on network devices \Nsuch as switches or routers.
Dialogue: 0,0:00:57.93,0:01:02.07,Default,,0000,0000,0000,,Unfortunately we use \Nthe same term for both
Dialogue: 0,0:01:02.11,0:01:06.03,Default,,0000,0000,0000,,but based on the context \Nit's it's usually clear
Dialogue: 0,0:01:06.57,0:01:09.33,Default,,0000,0000,0000,,what is meant or what \Nit is referring to.
Dialogue: 0,0:01:10.53,0:01:14.76,Default,,0000,0000,0000,,The transport layer provides \Nreliability if required.
Dialogue: 0,0:01:15.03,0:01:18.38,Default,,0000,0000,0000,,Well it depends on the kind of\Ntransfer protocol that is used
Dialogue: 0,0:01:19.01,0:01:23.22,Default,,0000,0000,0000,,and we do have different transport \Nlayer protocols
Dialogue: 0,0:01:23.22,0:01:26.46,Default,,0000,0000,0000,,so we can cater to different \Nrequirements of application.
Dialogue: 0,0:01:26.52,0:01:33.47,Default,,0000,0000,0000,,And since the transport layer\Nis responsible for transporting data
Dialogue: 0,0:01:33.47,0:01:36.79,Default,,0000,0000,0000,,from the source to the destination
Dialogue: 0,0:01:36.79,0:01:42.68,Default,,0000,0000,0000,,we also often refer to it \Nas an end to end concept.
Dialogue: 0,0:01:47.74,0:01:49.74,Default,,0000,0000,0000,,Alright.
Dialogue: 0,0:01:49.74,0:01:56.08,Default,,0000,0000,0000,,A very important concept on \Nthe transport layer is port numbers.
Dialogue: 0,0:01:56.62,0:02:03.53,Default,,0000,0000,0000,,So port numbers don't exist physically.\NIt's not a physical port.
Dialogue: 0,0:02:04.27,0:02:07.70,Default,,0000,0000,0000,,They are a logical concept \Nused by operating systems
Dialogue: 0,0:02:07.70,0:02:11.38,Default,,0000,0000,0000,,for the identification of \Ndifferent applications.
Dialogue: 0,0:02:12.68,0:02:17.30,Default,,0000,0000,0000,,Ports are identical but some \Nare actually recognized
Dialogue: 0,0:02:17.30,0:02:19.79,Default,,0000,0000,0000,,as specific applications for example.
Dialogue: 0,0:02:19.92,0:02:24.50,Default,,0000,0000,0000,,We talked about this in the first \Npart of the lecture DCP port 80
Dialogue: 0,0:02:24.54,0:02:30.66,Default,,0000,0000,0000,,is recognised as a HTTP \Nport 53 three can be UDP or DCP
Dialogue: 0,0:02:30.66,0:02:33.93,Default,,0000,0000,0000,,to recognise it's DNS and so on
Dialogue: 0,0:02:33.93,0:02:36.65,Default,,0000,0000,0000,,Some applications can also have\Nmultiple port numbers
Dialogue: 0,0:02:36.65,0:02:42.35,Default,,0000,0000,0000,,for example HTTP can also use\Nother port numbers such as 8080.
Dialogue: 0,0:02:42.35,0:02:47.82,Default,,0000,0000,0000,,And down here in the example you,\Nso if you figured it out
Dialogue: 0,0:02:47.82,0:02:50.13,Default,,0000,0000,0000,,Here you see two or more examples.
Dialogue: 0,0:02:50.13,0:02:56.21,Default,,0000,0000,0000,,So for electronic mail we have \Nport 110 for example
Dialogue: 0,0:02:56.21,0:03:01.31,Default,,0000,0000,0000,,if we use the proper three protocol \Nand Internet chat
Dialogue: 0,0:03:01.31,0:03:06.13,Default,,0000,0000,0000,,Internet chat application might use Port 531.
Dialogue: 0,0:03:06.62,0:03:15.92,Default,,0000,0000,0000,,OK, and the port numbers they are actually\Nencoded in the transport layer headers.
Dialogue: 0,0:03:25.64,0:03:31.44,Default,,0000,0000,0000,,The port numbers are sixteen \Nbit integer values.
Dialogue: 0,0:03:31.56,0:03:36.66,Default,,0000,0000,0000,,So the range is 0 to 65,535
Dialogue: 0,0:03:37.71,0:03:41.04,Default,,0000,0000,0000,,and this range is actually separated\Ninto three different regions.
Dialogue: 0,0:03:43.23,0:03:46.35,Default,,0000,0000,0000,,So three classes of ports.
Dialogue: 0,0:03:46.35,0:03:49.92,Default,,0000,0000,0000,,We have what's called\Nthe well known ports.
Dialogue: 0,0:03:49.92,0:03:54.25,Default,,0000,0000,0000,,Those are the ports from 0 to 1023.
Dialogue: 0,0:03:54.25,0:03:56.63,Default,,0000,0000,0000,,They're used for common services\Nand applications.
Dialogue: 0,0:03:56.64,0:04:05.89,Default,,0000,0000,0000,,So HTTP port 80 is one example\Nport 53 for DNS is another example
Dialogue: 0,0:04:06.61,0:04:14.69,Default,,0000,0000,0000,,or SDP we have port 25,\Nit's well known port for that protocol
Dialogue: 0,0:04:14.69,0:04:17.84,Default,,0000,0000,0000,,Then above that range \Nof well-known ports
Dialogue: 0,0:04:17.84,0:04:26.69,Default,,0000,0000,0000,,we have the range of registered ports\Nwhich range from 1024 to 49,151
Dialogue: 0,0:04:26.69,0:04:31.46,Default,,0000,0000,0000,,So those are ports for less common\Nuse services so applications.
Dialogue: 0,0:04:31.58,0:04:37.63,Default,,0000,0000,0000,,Couple of examples here, \Nso OpenVPN uses Port 1194
Dialogue: 0,0:04:37.70,0:04:45.89,Default,,0000,0000,0000,,CIP which is used in the context of \Nvoice over IP uses port 5060.
Dialogue: 0,0:04:47.13,0:04:50.37,Default,,0000,0000,0000,,And above that range \Nwe have what's called
Dialogue: 0,0:04:50.52,0:04:58.23,Default,,0000,0000,0000,,dynamic or private ports so all the ports,\N49,151 until the end of the range.
Dialogue: 0,0:04:58.23,0:05:03.87,Default,,0000,0000,0000,,They're dynamic ports and they're \Nused for client initiated sessions.
Dialogue: 0,0:05:03.93,0:05:10.54,Default,,0000,0000,0000,,So these ports are dynamically \Nassigned to client applications.
Dialogue: 0,0:05:11.83,0:05:16.37,Default,,0000,0000,0000,,And if you want to know \Nmore there's a full list available
Dialogue: 0,0:05:16.37,0:05:22.25,Default,,0000,0000,0000,,you can go to that Wikipedia page.
Dialogue: 0,0:05:22.47,0:05:24.82,Default,,0000,0000,0000,,Alright, so here's another example\Non the slide,
Dialogue: 0,0:05:24.82,0:05:32.25,Default,,0000,0000,0000,,So in this example we have clients that\Nuse private ports to initiate sessions.
Dialogue: 0,0:05:33.16,0:05:37.00,Default,,0000,0000,0000,,And we have some uh \Napplications you're running on
Dialogue: 0,0:05:37.14,0:05:40.67,Default,,0000,0000,0000,,well known ports and...
Dialogue: 0,0:05:40.91,0:05:46.22,Default,,0000,0000,0000,,Yeah. Keep in mind the source port does \Nnot need to match the destination port.
Dialogue: 0,0:05:46.22,0:05:52.01,Default,,0000,0000,0000,,Some protocols where that is \Nthe case or maybe the case
Dialogue: 0,0:05:52.08,0:05:56.06,Default,,0000,0000,0000,,many probably from applications \Nthat are peer to peer applications
Dialogue: 0,0:05:56.57,0:06:02.30,Default,,0000,0000,0000,,but in general the source code\Ndoes not need to match
Dialogue: 0,0:06:02.30,0:06:06.35,Default,,0000,0000,0000,,destination port and is often different. \NIn this example down here
Dialogue: 0,0:06:06.35,0:06:11.92,Default,,0000,0000,0000,,we have one server that runs an HTTP \Nserver port 80
Dialogue: 0,0:06:11.92,0:06:17.42,Default,,0000,0000,0000,,and SMCP server port 25, \Nand we have two clients
Dialogue: 0,0:06:17.45,0:06:21.49,Default,,0000,0000,0000,,client one on the side,\Nclient two on the other side
Dialogue: 0,0:06:21.49,0:06:26.77,Default,,0000,0000,0000,,and a client who makes an HTTP \Nrequest to the server
Dialogue: 0,0:06:26.77,0:06:32.86,Default,,0000,0000,0000,,and it picks a random \Nport out of this dynamic range
Dialogue: 0,0:06:32.92,0:06:38.38,Default,,0000,0000,0000,,which is here in this example port \N49,152.
Dialogue: 0,0:06:38.52,0:06:43.46,Default,,0000,0000,0000,,And then of course the HTTP request \Nmust be sent to the port
Dialogue: 0,0:06:43.46,0:06:46.90,Default,,0000,0000,0000,,on which the server application \Nis listening
Dialogue: 0,0:06:46.90,0:06:53.89,Default,,0000,0000,0000,,and that's port 80 of course \Nand the server responds.
Dialogue: 0,0:06:54.20,0:06:57.44,Default,,0000,0000,0000,,So we assume that that HTTP request \Ngoes to your server
Dialogue: 0,0:06:57.44,0:06:59.69,Default,,0000,0000,0000,,and the server responds.
Dialogue: 0,0:06:59.69,0:07:03.94,Default,,0000,0000,0000,,The server response obviously\Nthen comes from source port 80
Dialogue: 0,0:07:03.94,0:07:06.91,Default,,0000,0000,0000,,and it goes to the clients port.
Dialogue: 0,0:07:06.95,0:07:10.64,Default,,0000,0000,0000,,So the destination port \Nwill be 49,152
Dialogue: 0,0:07:11.06,0:07:14.91,Default,,0000,0000,0000,,And basically the same thing \Nhappens over here with clients two
Dialogue: 0,0:07:14.91,0:07:17.78,Default,,0000,0000,0000,,who wants to send an email.
Dialogue: 0,0:07:18.06,0:07:21.86,Default,,0000,0000,0000,,The client has selected a \Ndynamic port here of the range
Dialogue: 0,0:07:22.25,0:07:27.77,Default,,0000,0000,0000,,port 51152 and for the request \Nthe destination port is the port,
Dialogue: 0,0:07:27.77,0:07:30.78,Default,,0000,0000,0000,,the well known port of \Nthe SCDP so port 25
Dialogue: 0,0:07:31.43,0:07:34.01,Default,,0000,0000,0000,,and then when the response \Ncomes back from the server
Dialogue: 0,0:07:34.01,0:07:39.53,Default,,0000,0000,0000,,the response comes from port \Ntwenty five and it goes to
Dialogue: 0,0:07:39.53,0:07:44.44,Default,,0000,0000,0000,,that dynamic port that the client \Nput in the source profile
Dialogue: 0,0:07:44.44,0:07:52.04,Default,,0000,0000,0000,,of the request which is Port 51152 \Nso hopefully this makes
Dialogue: 0,0:07:52.04,0:07:57.14,Default,,0000,0000,0000,,the concept of dynamic ports \Nand well-known ports clearer.
Dialogue: 0,0:07:57.83,0:08:03.91,Default,,0000,0000,0000,,So let's move on to the transport \Nlayer protocols that we will discuss.
Dialogue: 0,0:08:03.91,0:08:06.17,Default,,0000,0000,0000,,In this part of \Nthe lecture we will talk about
Dialogue: 0,0:08:06.17,0:08:10.58,Default,,0000,0000,0000,,the two most common transport \Nlayer protocols
Dialogue: 0,0:08:10.58,0:08:16.00,Default,,0000,0000,0000,,the Transmission Control Protocol, TCP \Nand the User Data protocol, UDP.
Dialogue: 0,0:08:16.00,0:08:19.97,Default,,0000,0000,0000,,TCP is used when\Nthe delivery of data must be reliable
Dialogue: 0,0:08:20.00,0:08:23.51,Default,,0000,0000,0000,,for example filed downloads, \Nfor feature streaming ,
Dialogue: 0,0:08:23.51,0:08:27.59,Default,,0000,0000,0000,,for loading web pages.\NAddress UDP is used when
Dialogue: 0,0:08:27.59,0:08:33.03,Default,,0000,0000,0000,,the delivery of data must be timely \Nand doesn't need to be reliable.
Dialogue: 0,0:08:33.11,0:08:38.84,Default,,0000,0000,0000,,So things like voice over IP,\Nvideo communications
Dialogue: 0,0:08:38.84,0:08:41.93,Default,,0000,0000,0000,,especially real time sort of video\Ncommunications
Dialogue: 0,0:08:41.93,0:08:45.55,Default,,0000,0000,0000,,they make use of UDP \Nas well as online games
Dialogue: 0,0:08:45.55,0:08:49.79,Default,,0000,0000,0000,,where delay is to be avoided.
Dialogue: 0,0:08:50.00,0:08:55.53,Default,,0000,0000,0000,,So in fact first person shooter games\Nthey are usually based on UDP.
Dialogue: 0,0:08:55.53,0:08:58.96,Default,,0000,0000,0000,,There are other transport protocols.
Dialogue: 0,0:08:59.23,0:09:05.88,Default,,0000,0000,0000,,So it is actually not just TCP and UDP \Nbut these other protocols
Dialogue: 0,0:09:05.88,0:09:07.90,Default,,0000,0000,0000,,are not that widely used.
Dialogue: 0,0:09:07.90,0:09:13.01,Default,,0000,0000,0000,,So two examples are Stream \NControl Transmission Protocol, SCTP.
Dialogue: 0,0:09:13.01,0:09:19.79,Default,,0000,0000,0000,,Actually SCTP is fairly \Nwell used in the some of the
Dialogue: 0,0:09:20.84,0:09:24.77,Default,,0000,0000,0000,,Telcom companies because \Nthey use that as transport protocol
Dialogue: 0,0:09:24.77,0:09:28.33,Default,,0000,0000,0000,,for signalling. That's just used\Nin the signaling network
Dialogue: 0,0:09:28.33,0:09:33.06,Default,,0000,0000,0000,,but in a wider internet it \Nis not very widely used.
Dialogue: 0,0:09:33.58,0:09:36.49,Default,,0000,0000,0000,,We also have the Datagram \NCongestion Control Protocol
Dialogue: 0,0:09:36.49,0:09:42.37,Default,,0000,0000,0000,,DCCP, another transport protocol\Nthat's not very widely used.
Dialogue: 0,0:09:43.48,0:09:49.20,Default,,0000,0000,0000,,So in the remainder of this part\Nwe'll talk about a TTP protocol first
Dialogue: 0,0:09:49.20,0:09:54.10,Default,,0000,0000,0000,,because it is way more complicated\Nand it's a lot more to say,
Dialogue: 0,0:09:55.07,0:10:00.16,Default,,0000,0000,0000,,and then we'll talk about UDP which is \Nactually a fairly simple protocol
Dialogue: 0,0:10:00.24,0:10:05.91,Default,,0000,0000,0000,,and then we'll end up with a little bit\Nof a comparison between the two
Dialogue: 0,0:10:07.39,0:10:12.89,Default,,0000,0000,0000,,and for which type of applications \Nwe should use TCP
Dialogue: 0,0:10:12.89,0:10:18.49,Default,,0000,0000,0000,,and for which we should use UDP,\NWe'll discuss that at the end.
Dialogue: 0,0:10:18.54,0:10:23.40,Default,,0000,0000,0000,,Alright let's talk about TCP.
Dialogue: 0,0:10:25.73,0:10:29.27,Default,,0000,0000,0000,,TCP is a connection oriented protocol.
Dialogue: 0,0:10:29.28,0:10:33.27,Default,,0000,0000,0000,,It means that the communications \Nbetween two devices
Dialogue: 0,0:10:33.27,0:10:38.43,Default,,0000,0000,0000,,must be explicitly initiated \Nand terminated.
Dialogue: 0,0:10:38.96,0:10:41.78,Default,,0000,0000,0000,,Not all transport layer protocols \Nare connection oriented
Dialogue: 0,0:10:41.78,0:10:45.16,Default,,0000,0000,0000,,so UDP is not connection oriented.
Dialogue: 0,0:10:45.58,0:10:52.47,Default,,0000,0000,0000,,So the first thing \Nto establish a TCP connction
Dialogue: 0,0:10:53.55,0:10:59.45,Default,,0000,0000,0000,,is a handshake process that's known \Nas a three way handshake
Dialogue: 0,0:10:59.45,0:11:04.53,Default,,0000,0000,0000,,and consists of three steps \Nor three segments that are sent around
Dialogue: 0,0:11:04.53,0:11:07.95,Default,,0000,0000,0000,,and those are illustrated \Nin this figure here.
Dialogue: 0,0:11:08.58,0:11:12.13,Default,,0000,0000,0000,,So clearly identify but three \Nnumbers one two three.
Dialogue: 0,0:11:12.27,0:11:16.58,Default,,0000,0000,0000,,So at a first step the initiator \Nof the connection which is
Dialogue: 0,0:11:16.58,0:11:20.70,Default,,0000,0000,0000,,off the client will send \Na SEE to the other side
Dialogue: 0,0:11:21.86,0:11:26.46,Default,,0000,0000,0000,,of the server if the server \Nreceive the SEE
Dialogue: 0,0:11:26.46,0:11:31.10,Default,,0000,0000,0000,,the server will respond with the SYN AC \NAC for acknowledgment
Dialogue: 0,0:11:31.82,0:11:40.07,Default,,0000,0000,0000,,and then the handshake is completed \Nwith another act sent by A here
Dialogue: 0,0:11:40.07,0:11:43.16,Default,,0000,0000,0000,,over to B.
Dialogue: 0,0:11:43.16,0:11:47.50,Default,,0000,0000,0000,,After those three packets \Nhave been exchanged
Dialogue: 0,0:11:47.50,0:11:52.24,Default,,0000,0000,0000,,the TCP connection will sort of \Nmove into an established state
Dialogue: 0,0:11:52.27,0:11:59.80,Default,,0000,0000,0000,,and then data can be exchanged \Nbetween the two sides okay.
Dialogue: 0,0:11:59.83,0:12:03.41,Default,,0000,0000,0000,,So this is the way TCP \Nconnections are setup.
Dialogue: 0,0:12:04.68,0:12:09.57,Default,,0000,0000,0000,,On the next slide we'll \Ntalk about how connections
Dialogue: 0,0:12:09.57,0:12:15.35,Default,,0000,0000,0000,,are terminated so after a \Nconversation is complete
Dialogue: 0,0:12:16.24,0:12:21.74,Default,,0000,0000,0000,,the connection is terminated \Nusing either three or four steps.
Dialogue: 0,0:12:22.27,0:12:26.39,Default,,0000,0000,0000,,These steps illustrated \Nthis little picture down here.
Dialogue: 0,0:12:26.39,0:12:31.27,Default,,0000,0000,0000,,And so what happens is when a \Nconnection is terminated
Dialogue: 0,0:12:31.27,0:12:35.22,Default,,0000,0000,0000,,one side that wants to terminate \Nwill send what's called a FIN.
Dialogue: 0,0:12:35.26,0:12:39.39,Default,,0000,0000,0000,,The other side will receive \Nthe FIN and send it back.
Dialogue: 0,0:12:40.39,0:12:46.56,Default,,0000,0000,0000,,And sometime later will \Nand also sent a FIN and finally
Dialogue: 0,0:12:47.68,0:12:52.12,Default,,0000,0000,0000,,our station A here will send\Nan AC for that FIN
Dialogue: 0,0:12:52.14,0:12:55.36,Default,,0000,0000,0000,,as received a B \Nand at this point in time here
Dialogue: 0,0:12:55.36,0:13:01.42,Default,,0000,0000,0000,,the connection is \Ncompletely terminated.
Dialogue: 0,0:13:02.14,0:13:08.02,Default,,0000,0000,0000,,So this is either a three way \Nor a four way process because
Dialogue: 0,0:13:09.13,0:13:13.91,Default,,0000,0000,0000,,in many cases the AC here \Nis sent by B at the FIN
Dialogue: 0,0:13:14.08,0:13:17.59,Default,,0000,0000,0000,,they can be combined \Ninto a single segment.
Dialogue: 0,0:13:17.59,0:13:20.15,Default,,0000,0000,0000,,So we actually only need three \Nsegments, A will send FIN
Dialogue: 0,0:13:20.30,0:13:26.51,Default,,0000,0000,0000,,B will send a combined AC FIN \Nand then A will send back AC.
Dialogue: 0,0:13:26.51,0:13:34.02,Default,,0000,0000,0000,,But in some cases we actually may have \Nthe full sort of four step process.
Dialogue: 0,0:13:36.76,0:13:43.10,Default,,0000,0000,0000,,And on the next sort of \Nslide I will discuss why
Dialogue: 0,0:13:43.10,0:13:47.29,Default,,0000,0000,0000,,we actually need a sort of slightly \Nmore complicated process.
Dialogue: 0,0:13:47.29,0:13:54.22,Default,,0000,0000,0000,,The fourth step process rather than \Njust having three messages.
Dialogue: 0,0:13:54.22,0:14:02.53,Default,,0000,0000,0000,,So here's two questions for you regarding \Nthe setup and tear down of TCP connections
Dialogue: 0,0:14:02.73,0:14:06.36,Default,,0000,0000,0000,,Why do we actually need \Na three way handshake?
Dialogue: 0,0:14:06.45,0:14:09.06,Default,,0000,0000,0000,,isn't two handshakes sufficient?
Dialogue: 0,0:14:09.06,0:14:13.21,Default,,0000,0000,0000,,So two handshakes as in \NA to send a signal to B
Dialogue: 0,0:14:13.21,0:14:16.75,Default,,0000,0000,0000,,and B responds back.
Dialogue: 0,0:14:16.75,0:14:25.13,Default,,0000,0000,0000,,So why isn't that two way\Nhandshake sufficient?
Dialogue: 0,0:14:26.12,0:14:33.54,Default,,0000,0000,0000,,The reason this we need at least three\Npackets so that both sides
Dialogue: 0,0:14:33.89,0:14:39.21,Default,,0000,0000,0000,,can be sure that the connection \Nis to be established.
Dialogue: 0,0:14:40.18,0:14:43.05,Default,,0000,0000,0000,,Think about if we only had \Na two way handshake.
Dialogue: 0,0:14:43.06,0:14:47.02,Default,,0000,0000,0000,,So we only had this first packet \Nhere and a second packet here.
Dialogue: 0,0:14:47.02,0:14:51.46,Default,,0000,0000,0000,,Well there's no guarantee that \Nthat AC here from B to A
Dialogue: 0,0:14:52.12,0:14:57.31,Default,,0000,0000,0000,,actually arrives at , the AC could \Nbe lost inside the network.
Dialogue: 0,0:14:57.31,0:15:03.53,Default,,0000,0000,0000,,And so then we had the problem that\NA would treat the connection as...
Dialogue: 0,0:15:03.53,0:15:07.14,Default,,0000,0000,0000,,sorry, B would treat \Nthe connection as established.
Dialogue: 0,0:15:07.21,0:15:13.07,Default,,0000,0000,0000,,Assuming that the AC would arrive at A\Nbut A actually never receives the AC
Dialogue: 0,0:15:13.54,0:15:17.25,Default,,0000,0000,0000,,and A would treat the connection \Nas not established
Dialogue: 0,0:15:17.25,0:15:19.26,Default,,0000,0000,0000,,because it hasn't received the AC
Dialogue: 0,0:15:19.63,0:15:23.24,Default,,0000,0000,0000,,So only view that third packet here\Ngoing from A to B
Dialogue: 0,0:15:23.65,0:15:26.28,Default,,0000,0000,0000,,both A and B can be sure
Dialogue: 0,0:15:26.62,0:15:30.41,Default,,0000,0000,0000,,that the connection is in \Nan established state.
Dialogue: 0,0:15:30.42,0:15:33.15,Default,,0000,0000,0000,,Second question down here is why \Ndo we have full message.
Dialogue: 0,0:15:33.15,0:15:34.95,Default,,0000,0000,0000,,Why do we have four messages \Nhere down
Dialogue: 0,0:15:36.09,0:15:39.17,Default,,0000,0000,0000,,rather than having only three messages.
Dialogue: 0,0:15:39.24,0:15:42.18,Default,,0000,0000,0000,,And again the four messages\Nis not always happening.
Dialogue: 0,0:15:42.18,0:15:46.44,Default,,0000,0000,0000,,We may have three messages \Nat times.
Dialogue: 0,0:15:47.16,0:15:53.08,Default,,0000,0000,0000,,But why have four messages \Nin the extreme case, why is that?
Dialogue: 0,0:15:53.08,0:16:01.29,Default,,0000,0000,0000,,Well simple answer is that TCP \Nactually supports half closed connections.
Dialogue: 0,0:16:01.29,0:16:06.02,Default,,0000,0000,0000,,So it supports the case \Nwhere one side is closing
Dialogue: 0,0:16:06.02,0:16:10.13,Default,,0000,0000,0000,,its side of the connection \Nbut the other side still sending data
Dialogue: 0,0:16:10.88,0:16:15.68,Default,,0000,0000,0000,,and this only works with a \Nfour way sort of message tear down.
Dialogue: 0,0:16:15.68,0:16:20.96,Default,,0000,0000,0000,,So in this example, imagine for example\Nthat A wants to close
Dialogue: 0,0:16:20.96,0:16:24.14,Default,,0000,0000,0000,,because A does not have any data \Nto send any more
Dialogue: 0,0:16:24.14,0:16:27.03,Default,,0000,0000,0000,,so A sends a FIN which is acknowledged \Nby B with an AC
Dialogue: 0,0:16:27.03,0:16:29.52,Default,,0000,0000,0000,,but B actually still has data that\Nneeds to be sent to A
Dialogue: 0,0:16:29.52,0:16:34.23,Default,,0000,0000,0000,,so rather than sending this FIN \Nimmediately here
Dialogue: 0,0:16:34.23,0:16:38.68,Default,,0000,0000,0000,,B will continue sending data \Nand then only when B has sent all the data
Dialogue: 0,0:16:38.68,0:16:42.30,Default,,0000,0000,0000,,it will close its end \Nof the connection sending the FIN,
Dialogue: 0,0:16:42.99,0:16:48.23,Default,,0000,0000,0000,,and then that is acknowledged by the AC \Nfrom A and then at that stage here,
Dialogue: 0,0:16:48.36,0:16:50.48,Default,,0000,0000,0000,,the connection is fully closed.
Dialogue: 0,0:16:50.48,0:16:53.58,Default,,0000,0000,0000,,So that the four message tear \Ndown allows us to do
Dialogue: 0,0:16:54.27,0:16:56.94,Default,,0000,0000,0000,,a half close on the connection basically
Dialogue: 0,0:16:56.94,0:17:02.81,Default,,0000,0000,0000,,or close one side \Nand keep the other side open.
Dialogue: 0,0:17:05.41,0:17:10.78,Default,,0000,0000,0000,,There is a little activity \Non Cisco network and then a CAT here
Dialogue: 0,0:17:10.78,0:17:14.86,Default,,0000,0000,0000,,about TCP connection \Nand termination process.
Dialogue: 0,0:17:16.27,0:17:18.95,Default,,0000,0000,0000,,I will quickly show you but I want you\Nto do the whole activity
Dialogue: 0,0:17:18.95,0:17:23.39,Default,,0000,0000,0000,,I'll leave that for you as homework.
Dialogue: 0,0:17:23.47,0:17:25.03,Default,,0000,0000,0000,,Bear with me for a second.
Dialogue: 0,0:17:26.59,0:17:30.12,Default,,0000,0000,0000,,So here is the activity.
Dialogue: 0,0:17:30.12,0:17:33.51,Default,,0000,0000,0000,,The first activity is basically \Nthe three way handshake
Dialogue: 0,0:17:33.51,0:17:39.92,Default,,0000,0000,0000,,and you're meant to sort\Nof drag those boxes over here
Dialogue: 0,0:17:39.92,0:17:42.09,Default,,0000,0000,0000,,into those fields here.
Dialogue: 0,0:17:42.56,0:17:47.49,Default,,0000,0000,0000,,Until that sort of process \Nis correctly labeled.
Dialogue: 0,0:17:47.84,0:17:49.40,Default,,0000,0000,0000,,And so it's pretty trivial.
Dialogue: 0,0:17:49.40,0:17:51.88,Default,,0000,0000,0000,,So I mean A sends a SEE to B, right.
Dialogue: 0,0:17:51.88,0:17:57.36,Default,,0000,0000,0000,,So then what it means is that we \Nhave a SEE received here
Dialogue: 0,0:17:57.36,0:18:01.39,Default,,0000,0000,0000,,and we can check for correctness.
Dialogue: 0,0:18:01.59,0:18:03.77,Default,,0000,0000,0000,,So that's correct.
Dialogue: 0,0:18:03.77,0:18:08.13,Default,,0000,0000,0000,,And then you can basically drag \Nand drop those other things over here
Dialogue: 0,0:18:08.13,0:18:10.32,Default,,0000,0000,0000,,up to here.
Dialogue: 0,0:18:10.42,0:18:15.16,Default,,0000,0000,0000,,Better learn how that handshake works,\Nyou better memorize it,
Dialogue: 0,0:18:15.16,0:18:19.24,Default,,0000,0000,0000,,and I think the other one, \Nso the second part of the activity
Dialogue: 0,0:18:19.24,0:18:21.35,Default,,0000,0000,0000,,is about the termination session.
Dialogue: 0,0:18:21.35,0:18:26.35,Default,,0000,0000,0000,,So again there's two boxes here\Ncalled FIN and AC
Dialogue: 0,0:18:26.90,0:18:30.75,Default,,0000,0000,0000,,and you'd have to sort of \Njust drag those into those fields
Dialogue: 0,0:18:30.75,0:18:34.25,Default,,0000,0000,0000,,to describe the termination process.
Dialogue: 0,0:18:36.70,0:18:41.55,Default,,0000,0000,0000,,OK, let's go back to the lecture slides.
Dialogue: 0,0:18:42.11,0:18:47.65,Default,,0000,0000,0000,,So now I want to talk about \Nthe various sort of properties
Dialogue: 0,0:18:47.65,0:18:53.73,Default,,0000,0000,0000,,that TCP gives us or gives \Nthe application and TCP
Dialogue: 0,0:18:53.73,0:18:57.53,Default,,0000,0000,0000,,has quite a bit of functionality \Nas you will see sort of.
Dialogue: 0,0:18:57.56,0:19:03.56,Default,,0000,0000,0000,,The first thing is that TCP provides \Nin order, delivery of segments
Dialogue: 0,0:19:03.56,0:19:09.85,Default,,0000,0000,0000,,to the application and it does \Nthat based on sequence numbers.
Dialogue: 0,0:19:09.86,0:19:14.30,Default,,0000,0000,0000,,So what happens is that sender here
Dialogue: 0,0:19:15.50,0:19:17.75,Default,,0000,0000,0000,,divides that data up into the segments
Dialogue: 0,0:19:18.17,0:19:22.19,Default,,0000,0000,0000,,and the segments are numbered \Nwith sequence numbers
Dialogue: 0,0:19:22.19,0:19:27.73,Default,,0000,0000,0000,,so example from one to six\Nand it sort of said in the first lecture
Dialogue: 0,0:19:27.90,0:19:30.33,Default,,0000,0000,0000,,an IP that works
Dialogue: 0,0:19:30.33,0:19:34.49,Default,,0000,0000,0000,,segments and packets that can take \Ndifferent parts through the network.
Dialogue: 0,0:19:34.50,0:19:37.82,Default,,0000,0000,0000,,So we'll have two possible \Nroutes here
Dialogue: 0,0:19:37.82,0:19:40.51,Default,,0000,0000,0000,,from the source to the destination \Nsome segments here,
Dialogue: 0,0:19:40.51,0:19:45.75,Default,,0000,0000,0000,,some segments or packets take this route,\Nbut others might take this route.
Dialogue: 0,0:19:45.81,0:19:48.46,Default,,0000,0000,0000,,So if they take different \Nroutes then
Dialogue: 0,0:19:48.46,0:19:52.26,Default,,0000,0000,0000,,they may actually arrive out of \Norder at the destination.
Dialogue: 0,0:19:52.26,0:19:59.41,Default,,0000,0000,0000,,So in this case we receive segment 1, 2, 6\N5, 4 and then 3
Dialogue: 0,0:19:59.41,0:20:02.67,Default,,0000,0000,0000,,so the orders obviously jumbled up.
Dialogue: 0,0:20:02.67,0:20:06.96,Default,,0000,0000,0000,,If we or the receiver here \Nif the stuck at the receiver would pass up
Dialogue: 0,0:20:07.26,0:20:12.26,Default,,0000,0000,0000,,the segments in this jumbled up order\Nthen obviously you can imagine that
Dialogue: 0,0:20:12.27,0:20:16.73,Default,,0000,0000,0000,,the application but get \Na lot of garbage basically
Dialogue: 0,0:20:16.73,0:20:18.99,Default,,0000,0000,0000,,and couldn't interpret that data.
Dialogue: 0,0:20:19.03,0:20:21.96,Default,,0000,0000,0000,,So whatever you're doing \Nlike if you send an email
Dialogue: 0,0:20:21.96,0:20:23.99,Default,,0000,0000,0000,,this would be completely garbled up.
Dialogue: 0,0:20:24.00,0:20:28.56,Default,,0000,0000,0000,,So what TCP does is it \Nreorders the segments
Dialogue: 0,0:20:29.01,0:20:32.56,Default,,0000,0000,0000,,back into the original order \Nbased on a sequence
Dialogue: 0,0:20:32.56,0:20:36.44,Default,,0000,0000,0000,,and as before it passes \Nthe segments to the application.
Dialogue: 0,0:20:36.45,0:20:40.25,Default,,0000,0000,0000,,So all the segments that are \Npassed to the applications
Dialogue: 0,0:20:40.25,0:20:45.54,Default,,0000,0000,0000,,they are passed in the order \Nthey were sent by the sender.
Dialogue: 0,0:20:45.81,0:20:51.22,Default,,0000,0000,0000,,So there's no reordering \Non top of TCP
Dialogue: 0,0:20:51.22,0:20:54.70,Default,,0000,0000,0000,,or in other words applications \Nthat use TCP
Dialogue: 0,0:20:54.70,0:21:00.72,Default,,0000,0000,0000,,can be assured that segments or packets \Nare not delivered...
Dialogue: 0,0:21:01.33,0:21:08.28,Default,,0000,0000,0000,,Not in the original order to \Nthe receiving application.
Dialogue: 0,0:21:08.32,0:21:13.20,Default,,0000,0000,0000,,The other thing TCP provides us with \Nis reliable transport
Dialogue: 0,0:21:13.20,0:21:16.81,Default,,0000,0000,0000,,so the sequence numbers are used \Nin conjunction with
Dialogue: 0,0:21:16.93,0:21:22.04,Default,,0000,0000,0000,,acknowledgement or Acs\Nor acknowledgement numbers
Dialogue: 0,0:21:22.04,0:21:28.59,Default,,0000,0000,0000,,to provide reliable data \Ntransport so all the data transmitted
Dialogue: 0,0:21:29.71,0:21:37.16,Default,,0000,0000,0000,,using TCP must be acknowledged \Nand an acknowledgement is cumulative.
Dialogue: 0,0:21:37.18,0:21:40.52,Default,,0000,0000,0000,,In TCP it means that it \Nalso acknowledges
Dialogue: 0,0:21:40.52,0:21:46.14,Default,,0000,0000,0000,,all the preceding segments that \Nwere received
Dialogue: 0,0:21:46.14,0:21:50.80,Default,,0000,0000,0000,,after the last acknowledgement that \Nhas been received.
Dialogue: 0,0:21:50.80,0:21:57.17,Default,,0000,0000,0000,,And receivers always acknowledge with \Nthe next expected badge.
Dialogue: 0,0:21:57.25,0:21:58.39,Default,,0000,0000,0000,,Keep that in mind.
Dialogue: 0,0:21:58.51,0:22:02.16,Default,,0000,0000,0000,,So if we look at the example \Nover here we have a sender
Dialogue: 0,0:22:02.16,0:22:06.43,Default,,0000,0000,0000,,and we have a receiver \Nand this example also
Dialogue: 0,0:22:06.43,0:22:09.25,Default,,0000,0000,0000,,introduces us to the concept \Nof window size
Dialogue: 0,0:22:09.25,0:22:12.64,Default,,0000,0000,0000,,we'll come back to that on some \Nof the following slides.
Dialogue: 0,0:22:12.73,0:22:17.62,Default,,0000,0000,0000,,So window is basically the amount of \Ndata that TCP can have in flight
Dialogue: 0,0:22:17.65,0:22:21.45,Default,,0000,0000,0000,,and acknowledge and so in this \Ncase it's 300 bytes.
Dialogue: 0,0:22:21.46,0:22:24.13,Default,,0000,0000,0000,,And so this is why the sender \Ncan send two
Dialogue: 0,0:22:24.88,0:22:28.37,Default,,0000,0000,0000,,1500 byte segments here \Nover to the receiver.
Dialogue: 0,0:22:28.37,0:22:30.44,Default,,0000,0000,0000,,and the receiver receive those two
Dialogue: 0,0:22:31.31,0:22:33.83,Default,,0000,0000,0000,,and then the receiver will \Nsend an acknowledgement
Dialogue: 0,0:22:34.34,0:22:37.10,Default,,0000,0000,0000,,for both of these and you can \Nsee that the acknowledged number here
Dialogue: 0,0:22:37.10,0:22:41.24,Default,,0000,0000,0000,,is 3001, which is the next expected byte.
Dialogue: 0,0:22:41.24,0:22:44.26,Default,,0000,0000,0000,,So the receiver has received all the bytes\Nfor one to 3000.
Dialogue: 0,0:22:44.27,0:22:47.57,Default,,0000,0000,0000,,The next expected \Nbyte is 3001.
Dialogue: 0,0:22:47.87,0:22:51.26,Default,,0000,0000,0000,,Well when the sender gets \Nacknowledgment the sender
Dialogue: 0,0:22:51.26,0:22:54.35,Default,,0000,0000,0000,,sort of sends more segments \Nsends another two segments
Dialogue: 0,0:22:54.35,0:22:59.38,Default,,0000,0000,0000,,down here with the bytes \N3001 to 6000
Dialogue: 0,0:22:59.38,0:23:02.88,Default,,0000,0000,0000,,and again the receiver will acknowledge.
Dialogue: 0,0:23:03.02,0:23:06.79,Default,,0000,0000,0000,,both of these segments \Nhere with one acknowledgement
Dialogue: 0,0:23:06.79,0:23:14.96,Default,,0000,0000,0000,,and it will have the number \N6001 because that is the next byte
Dialogue: 0,0:23:15.08,0:23:22.84,Default,,0000,0000,0000,,the receiver expects \Nthe sender to send OK.
Dialogue: 0,0:23:23.77,0:23:29.95,Default,,0000,0000,0000,,Let's sort of go a bit more \Ninto the details here.
Dialogue: 0,0:23:29.95,0:23:35.86,Default,,0000,0000,0000,,So when segments are not \Nacknowledged within the time limit
Dialogue: 0,0:23:35.89,0:23:38.53,Default,,0000,0000,0000,,so in the best case they \Nare acknowledged
Dialogue: 0,0:23:38.53,0:23:42.16,Default,,0000,0000,0000,,like in a previous slide this is \Nwhen everything goes perfectly fine
Dialogue: 0,0:23:42.16,0:23:46.19,Default,,0000,0000,0000,,but if things are not going that well \Nand segments are not acknowledged
Dialogue: 0,0:23:46.19,0:23:50.76,Default,,0000,0000,0000,,within some time limit they need \Nto be re-transmitted by the sender.
Dialogue: 0,0:23:51.16,0:23:54.62,Default,,0000,0000,0000,,Segments can be lost due to \Nnetwork congestion
Dialogue: 0,0:23:54.89,0:23:57.35,Default,,0000,0000,0000,,or interruptions to the medium.
Dialogue: 0,0:23:57.62,0:24:00.100,Default,,0000,0000,0000,,If somebody I don't know,\Ntakes out a cable or something like that
Dialogue: 0,0:24:00.100,0:24:04.67,Default,,0000,0000,0000,,or falls in the hardware\Nof course.
Dialogue: 0,0:24:04.67,0:24:09.24,Default,,0000,0000,0000,,Data received after a loss\Nis not acknowledged.
Dialogue: 0,0:24:09.24,0:24:13.95,Default,,0000,0000,0000,,This is illustrated in \Nthe figure over here.
Dialogue: 0,0:24:13.95,0:24:19.13,Default,,0000,0000,0000,,So here we have the case that \Neverything was fine at the start
Dialogue: 0,0:24:19.17,0:24:23.68,Default,,0000,0000,0000,,but then when the sender sends \Ntwo more segments here
Dialogue: 0,0:24:23.68,0:24:28.41,Default,,0000,0000,0000,,the first of those segments is actually \Nlost because it's dropped
Dialogue: 0,0:24:28.41,0:24:32.19,Default,,0000,0000,0000,,somewhere in the network and it \Nnever arrives at the receiver.
Dialogue: 0,0:24:32.20,0:24:38.12,Default,,0000,0000,0000,,So then what the receiver will do \Nis despite having received
Dialogue: 0,0:24:38.12,0:24:45.46,Default,,0000,0000,0000,,that later segment here covering \Nthe bytes between 4501 and 6000.
Dialogue: 0,0:24:45.66,0:24:52.46,Default,,0000,0000,0000,,Since TCP does not acknowledge bytes \Nafter loss
Dialogue: 0,0:24:52.46,0:24:58.76,Default,,0000,0000,0000,,it will send back another acknowledgement\Nwith the number 3001
Dialogue: 0,0:24:59.36,0:25:04.47,Default,,0000,0000,0000,,because that is the number up to \Nat which point we've received
Dialogue: 0,0:25:04.47,0:25:10.17,Default,,0000,0000,0000,,you know, a continuous stream of segments\Nand then we've lost a segment
Dialogue: 0,0:25:10.17,0:25:13.43,Default,,0000,0000,0000,,and we received another segment \Nafter that
Dialogue: 0,0:25:13.43,0:25:18.50,Default,,0000,0000,0000,,but we do not acknowledge any \Nsegments received after loss.
Dialogue: 0,0:25:18.50,0:25:24.47,Default,,0000,0000,0000,,We'll sort of acknowledge whatever we\Nhave received before the loss.
Dialogue: 0,0:25:24.47,0:25:30.66,Default,,0000,0000,0000,,Actually there is a mechanism to \Nacknowledge segments
Dialogue: 0,0:25:30.66,0:25:32.64,Default,,0000,0000,0000,,received after a loss.
Dialogue: 0,0:25:32.64,0:25:37.54,Default,,0000,0000,0000,,It's called selective acknowledgements\Nbut it's out of the scope of the unit.
Dialogue: 0,0:25:37.68,0:25:42.99,Default,,0000,0000,0000,,So this is a bit more complicated than
Dialogue: 0,0:25:43.05,0:25:46.05,Default,,0000,0000,0000,,the simple sort of \Nacknowledgement we discuss here
Dialogue: 0,0:25:46.86,0:25:50.46,Default,,0000,0000,0000,,and it's implemented to \Nbe much more efficient
Dialogue: 0,0:25:51.81,0:25:55.72,Default,,0000,0000,0000,,since of course what \Nhappens in this case here.
Dialogue: 0,0:25:56.19,0:26:01.50,Default,,0000,0000,0000,,Once the receiver acknowledges \Nor it sends acknowledgement number 3001.
Dialogue: 0,0:26:01.50,0:26:08.00,Default,,0000,0000,0000,,Of course what happens is the sender \Nwill resend this segment here
Dialogue: 0,0:26:09.15,0:26:17.26,Default,,0000,0000,0000,,starting with byte 3001 as well as\Nthe next segment starting with byte 4001.
Dialogue: 0,0:26:17.46,0:26:19.89,Default,,0000,0000,0000,,So despite the fact that \Nthis segment the second here
Dialogue: 0,0:26:19.89,0:26:24.21,Default,,0000,0000,0000,,was already received with cumulative\Nacknowledgements
Dialogue: 0,0:26:24.21,0:26:25.92,Default,,0000,0000,0000,,we'll have to resend
Dialogue: 0,0:26:25.95,0:26:29.55,Default,,0000,0000,0000,,or the sender has to resend \Nthis again as well.
Dialogue: 0,0:26:29.55,0:26:32.97,Default,,0000,0000,0000,,And so with selective ACs \Nwe can do this way more efficiently
Dialogue: 0,0:26:32.97,0:26:35.00,Default,,0000,0000,0000,,but it's also \Nway more complicated.
Dialogue: 0,0:26:35.07,0:26:40.97,Default,,0000,0000,0000,,So it's out of scope of \Nthe discussion here.
Dialogue: 0,0:26:41.11,0:26:43.91,Default,,0000,0000,0000,,Next I want to talk about \Nanother feature of TCP
Dialogue: 0,0:26:43.91,0:26:47.97,Default,,0000,0000,0000,,which is called congestion control \NTTP uses congestion control
Dialogue: 0,0:26:47.97,0:26:50.92,Default,,0000,0000,0000,,to manage the rate \Nof transmission.
Dialogue: 0,0:26:50.92,0:26:55.73,Default,,0000,0000,0000,,So you can think about it as \Nan accelerator and brake
Dialogue: 0,0:26:55.73,0:27:01.63,Default,,0000,0000,0000,,on the rate of the transmission \Nand the TCP congestion window
Dialogue: 0,0:27:01.63,0:27:04.34,Default,,0000,0000,0000,,specifies the maximum \Nnumber of unacknowledged segments
Dialogue: 0,0:27:04.34,0:27:07.43,Default,,0000,0000,0000,,that can be in-flight \Nfrom sender to receiver.
Dialogue: 0,0:27:08.44,0:27:11.76,Default,,0000,0000,0000,,Why do we actually \Nhave congestion control?
Dialogue: 0,0:27:11.76,0:27:15.35,Default,,0000,0000,0000,,Well let's do a little sort \Nof thought experiment here.
Dialogue: 0,0:27:15.55,0:27:21.15,Default,,0000,0000,0000,,What if TCP senders could only send \None packet at a time without AC
Dialogue: 0,0:27:21.15,0:27:24.16,Default,,0000,0000,0000,,If the round trip delay \Nbetween the sender and receiver
Dialogue: 0,0:27:24.16,0:27:28.69,Default,,0000,0000,0000,,was something like two hundred \Nmilliseconds then you know it would mean
Dialogue: 0,0:27:28.69,0:27:32.19,Default,,0000,0000,0000,,that TCP could only \Nsend five packets per second.
Dialogue: 0,0:27:32.24,0:27:39.49,Default,,0000,0000,0000,,That would be very very slow .\Ncertainly we wouldn't congest
Dialogue: 0,0:27:39.49,0:27:44.47,Default,,0000,0000,0000,,the network but the TCP performance \Nwould be horribly slow.
Dialogue: 0,0:27:44.47,0:27:49.37,Default,,0000,0000,0000,,So what if on the other hand TCPs \Nsenders could sent
Dialogue: 0,0:27:49.37,0:27:53.83,Default,,0000,0000,0000,,as fast as a LAN connection permits for \Nexample of one gigabit per second.
Dialogue: 0,0:27:54.13,0:27:57.94,Default,,0000,0000,0000,,Well the gateway to \Nthe Internet is usually a bottleneck,
Dialogue: 0,0:27:57.94,0:28:00.24,Default,,0000,0000,0000,,and the gateway to the Internet,
Dialogue: 0,0:28:00.25,0:28:05.84,Default,,0000,0000,0000,,If you think about home networks \Nfor example it's unlikely to be able
Dialogue: 0,0:28:05.84,0:28:09.55,Default,,0000,0000,0000,,to send with one gigabits \Nper second into the Internet.
Dialogue: 0,0:28:09.58,0:28:14.72,Default,,0000,0000,0000,,So then we get what is called \Ncongestion on the gateway.
Dialogue: 0,0:28:14.74,0:28:20.98,Default,,0000,0000,0000,,So packets are building up in \Nthe queues and eventually we have
Dialogue: 0,0:28:22.03,0:28:29.85,Default,,0000,0000,0000,,full queues and any further \Npackets arriving will be dropped.
Dialogue: 0,0:28:30.28,0:28:36.00,Default,,0000,0000,0000,,And you also need to consider \Nthat we share the resources
Dialogue: 0,0:28:36.53,0:28:39.74,Default,,0000,0000,0000,,we share the network with \Nmany many other users.
Dialogue: 0,0:28:40.02,0:28:45.80,Default,,0000,0000,0000,,So it's just a little picture here \Nto illustrate the links
Dialogue: 0,0:28:45.80,0:28:49.67,Default,,0000,0000,0000,,that carry traffic between \Ndifferent continents,
Dialogue: 0,0:28:49.86,0:28:52.100,Default,,0000,0000,0000,,and you can see there's quite \Na number of links between
Dialogue: 0,0:28:52.100,0:28:56.21,Default,,0000,0000,0000,,United States and Asia,\Nand United States with Europe.
Dialogue: 0,0:28:56.54,0:29:01.32,Default,,0000,0000,0000,,But it's not that many links connecting\NAustralia to the rest of the world.
Dialogue: 0,0:29:01.70,0:29:06.93,Default,,0000,0000,0000,,So these are usually fiber \Nlinks and you can imagine that
Dialogue: 0,0:29:06.93,0:29:10.97,Default,,0000,0000,0000,,those links you know that carry\Nthe traffic of,
Dialogue: 0,0:29:11.49,0:29:14.69,Default,,0000,0000,0000,,of billions or tens \Nor hundreds of millions
Dialogue: 0,0:29:14.69,0:29:16.92,Default,,0000,0000,0000,,of concurrent TCP connections.
Dialogue: 0,0:29:17.27,0:29:22.46,Default,,0000,0000,0000,,So all of these TCP connections \Nshare the links
Dialogue: 0,0:29:23.33,0:29:28.93,Default,,0000,0000,0000,,and so the question is how does \Na TCP sender
Dialogue: 0,0:29:29.05,0:29:35.27,Default,,0000,0000,0000,,find that the perfect rate, \Nso that fair share of a 100%
Dialogue: 0,0:29:35.27,0:29:40.53,Default,,0000,0000,0000,,utilized bottleneck link speed.
Dialogue: 0,0:29:43.97,0:29:49.13,Default,,0000,0000,0000,,So finding that you know that \Nperfect weight where we sort of
Dialogue: 0,0:29:49.34,0:29:54.57,Default,,0000,0000,0000,,fairly share that think with lots \Nand lots of other TCP connections.
Dialogue: 0,0:29:54.57,0:29:59.28,Default,,0000,0000,0000,,At the same time we'll utilize all \Nthe bandwidth or the capacity
Dialogue: 0,0:29:59.28,0:30:06.76,Default,,0000,0000,0000,,that it has while at the same time we'll \Ntry to avoid congestion in routers.
Dialogue: 0,0:30:06.83,0:30:12.57,Default,,0000,0000,0000,,Well that is the job of the congestion \Ncontrol algorithm inside TCP.
Dialogue: 0,0:30:13.07,0:30:16.87,Default,,0000,0000,0000,,And there are many congestion\Ncontrol algorithms.
Dialogue: 0,0:30:16.90,0:30:23.24,Default,,0000,0000,0000,,And on this slide also want to briefly\Nillustrate the new redo algorithm.
Dialogue: 0,0:30:23.41,0:30:26.47,Default,,0000,0000,0000,,It's one of the traditional \Nalgorithms that was
Dialogue: 0,0:30:26.47,0:30:31.72,Default,,0000,0000,0000,,the default algorithm for a long \Ntime in most operating systems.
Dialogue: 0,0:30:31.72,0:30:35.56,Default,,0000,0000,0000,,So that algorithm has two phases \Nand has a slow start phase
Dialogue: 0,0:30:35.56,0:30:42.23,Default,,0000,0000,0000,,and there's a congestion avoidance phase\Nand a slow start is actually not that slow
Dialogue: 0,0:30:42.23,0:30:44.62,Default,,0000,0000,0000,,despite the fact that \Nit's named slow start.
Dialogue: 0,0:30:44.71,0:30:49.08,Default,,0000,0000,0000,,So what slow start as is \Nor what TCP does
Dialogue: 0,0:30:49.08,0:30:52.01,Default,,0000,0000,0000,,Slow start is it starts with an initial.
Dialogue: 0,0:30:52.01,0:30:57.83,Default,,0000,0000,0000,,Congestion window of two segments or \Nthese days will actually use 10 segments,
Dialogue: 0,0:30:58.54,0:31:00.91,Default,,0000,0000,0000,,as the initial congestion window.
Dialogue: 0,0:31:00.91,0:31:04.24,Default,,0000,0000,0000,,And then the sender will increase\Nthe congestion window by one segment
Dialogue: 0,0:31:04.24,0:31:06.97,Default,,0000,0000,0000,,for every packet acknowledged \Nby the receiver.
Dialogue: 0,0:31:07.39,0:31:12.27,Default,,0000,0000,0000,,So this will lead to a relatively \Nquick increase in throughput
Dialogue: 0,0:31:12.27,0:31:16.44,Default,,0000,0000,0000,,up to the maximum possible fare share.
Dialogue: 0,0:31:16.44,0:31:20.21,Default,,0000,0000,0000,,By the time when the sender \Ndetects packet loss.
Dialogue: 0,0:31:20.47,0:31:27.07,Default,,0000,0000,0000,,It halves the window and then \Nit goes into congestion avoidance
Dialogue: 0,0:31:27.39,0:31:33.12,Default,,0000,0000,0000,,In the and avoidance \Nphase without loss,
Dialogue: 0,0:31:33.12,0:31:38.12,Default,,0000,0000,0000,,the window is increased by one\Nsegment for each round trip time.
Dialogue: 0,0:31:38.12,0:31:44.37,Default,,0000,0000,0000,,Round trip time means the time\Nit takes for a packet to go from A to B
Dialogue: 0,0:31:44.46,0:31:47.19,Default,,0000,0000,0000,,and a response to come \Nback from B to A.
Dialogue: 0,0:31:47.22,0:31:50.33,Default,,0000,0000,0000,,So that's that's a road trip \Nthat's a round trip time.
Dialogue: 0,0:31:50.33,0:31:53.52,Default,,0000,0000,0000,,So for each round trip sender will \Nincrease the window by one segment
Dialogue: 0,0:31:54.12,0:32:01.79,Default,,0000,0000,0000,,when the sender transmits to fast \Nand congests the link again,
Dialogue: 0,0:32:01.80,0:32:05.79,Default,,0000,0000,0000,,then it will mean that you know \Na congestion at the router occurs,
Dialogue: 0,0:32:06.65,0:32:10.25,Default,,0000,0000,0000,,queues also, \Nand there will be packet drops.
Dialogue: 0,0:32:10.25,0:32:15.42,Default,,0000,0000,0000,,When the sender detects those \Npacket drops it has its window
Dialogue: 0,0:32:16.16,0:32:20.53,Default,,0000,0000,0000,,So this quickly shrinking off the window\Nwill quickly reduce
Dialogue: 0,0:32:20.53,0:32:24.69,Default,,0000,0000,0000,,the throughput of the connection \Nbut it will also quickly reduce
Dialogue: 0,0:32:24.78,0:32:27.02,Default,,0000,0000,0000,,the congestion on the bottleneck.
Dialogue: 0,0:32:27.14,0:32:28.36,Default,,0000,0000,0000,,That's the idea.
Dialogue: 0,0:32:28.95,0:32:33.38,Default,,0000,0000,0000,,And then after that we'll \Nhave that sort of slow increase
Dialogue: 0,0:32:33.38,0:32:36.36,Default,,0000,0000,0000,,in one segment \Neach round trip time again.
Dialogue: 0,0:32:36.58,0:32:40.37,Default,,0000,0000,0000,,Where the sort of sender starts basically\Nsending more and more
Dialogue: 0,0:32:40.37,0:32:42.74,Default,,0000,0000,0000,,until we sort of hit the limit again.
Dialogue: 0,0:32:42.97,0:32:50.34,Default,,0000,0000,0000,,And to a sort of to better illustrate that\Nit's easiest to see this in a graph.
Dialogue: 0,0:32:50.38,0:32:52.53,Default,,0000,0000,0000,,This is an actual graph \Nof the congestion window
Dialogue: 0,0:32:52.54,0:32:57.25,Default,,0000,0000,0000,,of a single TCP connection \Ngoing through a bottleneck
Dialogue: 0,0:32:57.25,0:32:59.47,Default,,0000,0000,0000,,and you can \Nsee at the start here,
Dialogue: 0,0:32:59.48,0:33:03.63,Default,,0000,0000,0000,,slow start where we have a rapid increase\Nof the congestion window
Dialogue: 0,0:33:03.63,0:33:07.99,Default,,0000,0000,0000,,and then we have the first packet loss\Nand congestion we know sort of drops,
Dialogue: 0,0:33:08.02,0:33:12.92,Default,,0000,0000,0000,,halved, it's halved again \Nand then we go into congestion avoidanc
Dialogue: 0,0:33:12.92,0:33:14.95,Default,,0000,0000,0000,,and you can see us saw tooth pattern
Dialogue: 0,0:33:14.95,0:33:17.71,Default,,0000,0000,0000,,and congestion \Navoidance will basically...
Dialogue: 0,0:33:18.04,0:33:22.90,Default,,0000,0000,0000,,Will slowly increase \Nthe congestion window over time,
Dialogue: 0,0:33:22.90,0:33:26.57,Default,,0000,0000,0000,,but when it's one to time \Nand then at some stage
Dialogue: 0,0:33:26.57,0:33:28.93,Default,,0000,0000,0000,,we'll hit congestion again \Nif there's packet loss,
Dialogue: 0,0:33:28.93,0:33:31.12,Default,,0000,0000,0000,,will quickly \Nor the sender will quickly
Dialogue: 0,0:33:31.66,0:33:35.29,Default,,0000,0000,0000,,reduce the window to half of its size
Dialogue: 0,0:33:35.95,0:33:38.98,Default,,0000,0000,0000,,and then we'll start \Nthe upward probing again
Dialogue: 0,0:33:39.07,0:33:42.61,Default,,0000,0000,0000,,until we hit loss again \Nhalf a window and so on.
Dialogue: 0,0:33:42.61,0:33:45.95,Default,,0000,0000,0000,,So with a single flow through \Na bottleneck we get to see
Dialogue: 0,0:33:45.97,0:33:49.48,Default,,0000,0000,0000,,a perfect saw tooth pattern \Nof course with multiple flows.
Dialogue: 0,0:33:49.48,0:33:59.09,Default,,0000,0000,0000,,This will look much messier \Nso to come back to the point of congestion
Dialogue: 0,0:33:59.09,0:34:02.32,Default,,0000,0000,0000,,of congestion again so make it \Nvery clear what it means is
Dialogue: 0,0:34:02.75,0:34:05.40,Default,,0000,0000,0000,,so congestion occurs when \Nthe number of packets arriving
Dialogue: 0,0:34:05.40,0:34:10.48,Default,,0000,0000,0000,,at a router is higher than number of ACs \Nthat can be sent on the next link.
Dialogue: 0,0:34:10.52,0:34:14.28,Default,,0000,0000,0000,,So if we have lots of different\Ndevices here,
Dialogue: 0,0:34:14.28,0:34:17.64,Default,,0000,0000,0000,,all send packets to the router\Nthen sent to the Internet.
Dialogue: 0,0:34:17.96,0:34:21.05,Default,,0000,0000,0000,,And this is the one link to the Internet,\Nlet's say,
Dialogue: 0,0:34:21.08,0:34:29.31,Default,,0000,0000,0000,,and the link speed here of this link\Nis less than the combined link speeds
Dialogue: 0,0:34:29.69,0:34:32.61,Default,,0000,0000,0000,,for all these different devices then.
Dialogue: 0,0:34:32.96,0:34:36.74,Default,,0000,0000,0000,,Well we have to buffer \Npackets on the router
Dialogue: 0,0:34:37.45,0:34:42.20,Default,,0000,0000,0000,,if the packet rates are too high \Nor higher than this link, right?
Dialogue: 0,0:34:42.65,0:34:47.72,Default,,0000,0000,0000,,And if those rates are persistently \Nhigher then this link
Dialogue: 0,0:34:47.72,0:34:52.13,Default,,0000,0000,0000,,will then of course eventually \Nwill get filled with all of our buffers.
Dialogue: 0,0:34:52.43,0:34:56.01,Default,,0000,0000,0000,,And then the router has no choice \Nbut to drop packets.
Dialogue: 0,0:34:57.61,0:35:03.95,Default,,0000,0000,0000,,And then of course with TCP congestion \Ncontrol we have the fact that
Dialogue: 0,0:35:04.16,0:35:08.71,Default,,0000,0000,0000,,the TCP under senders \Nhere will take that bus
Dialogue: 0,0:35:08.71,0:35:10.68,Default,,0000,0000,0000,,as indication for congestion.
Dialogue: 0,0:35:10.88,0:35:14.95,Default,,0000,0000,0000,,The window will be halved\Nand all of those devices here
Dialogue: 0,0:35:14.95,0:35:17.15,Default,,0000,0000,0000,,will send a lot less packets.
Dialogue: 0,0:35:17.15,0:35:21.66,Default,,0000,0000,0000,,Which then means the queues,\Nthey can be drained,
Dialogue: 0,0:35:21.86,0:35:26.09,Default,,0000,0000,0000,,and we won't have any loss \Nsort of in there (INAUDIBLE)
Dialogue: 0,0:35:26.12,0:35:30.64,Default,,0000,0000,0000,,but again the window size \Nwill increase again.
Dialogue: 0,0:35:30.64,0:35:36.99,Default,,0000,0000,0000,,All those devices there was some sense of \Nfaster and faster rates
Dialogue: 0,0:35:36.99,0:35:40.68,Default,,0000,0000,0000,,based on the upward probing \Nof the congestion control algorithm
Dialogue: 0,0:35:40.68,0:35:45.50,Default,,0000,0000,0000,,until the queues become full again \Nand we'll have the next packet loss,
Dialogue: 0,0:35:45.50,0:35:49.40,Default,,0000,0000,0000,,and then we'll send less again\Nand so on.
Dialogue: 0,0:35:50.63,0:35:54.75,Default,,0000,0000,0000,,Now you might say okay \Nwell if the problem is packet loss
Dialogue: 0,0:35:54.75,0:35:59.53,Default,,0000,0000,0000,,if packets are full then why not make\Nthe router buffers really really big.
Dialogue: 0,0:36:00.18,0:36:04.02,Default,,0000,0000,0000,,So we can basically avoid any any \Npacket losses
Dialogue: 0,0:36:04.02,0:36:07.78,Default,,0000,0000,0000,,so we can have a case where either the \Ncombined sender rates
Dialogue: 0,0:36:07.78,0:36:09.03,Default,,0000,0000,0000,,can be higher than that
Dialogue: 0,0:36:09.03,0:36:12.18,Default,,0000,0000,0000,,then you communicate for \Na very very long time.
Dialogue: 0,0:36:12.62,0:36:16.64,Default,,0000,0000,0000,,If we have big buffers \Nyou can have it sort of
Dialogue: 0,0:36:16.65,0:36:18.86,Default,,0000,0000,0000,,for varying something \Nlike packet drops.
Dialogue: 0,0:36:19.17,0:36:23.72,Default,,0000,0000,0000,,And this is what quite a number of people\Nactually used to think for years
Dialogue: 0,0:36:23.72,0:36:28.57,Default,,0000,0000,0000,,and it led to a fairly large buffers \Nwhich caused another problem though
Dialogue: 0,0:36:28.57,0:36:31.32,Default,,0000,0000,0000,,which is referred to as buffered load.
Dialogue: 0,0:36:32.14,0:36:38.34,Default,,0000,0000,0000,,If buffer sizes are very large \Nthen that means also the latency
Dialogue: 0,0:36:38.34,0:36:42.37,Default,,0000,0000,0000,,will be quite high because \Npackets are stuck in those buffers
Dialogue: 0,0:36:42.37,0:36:43.91,Default,,0000,0000,0000,,for quite some time.
Dialogue: 0,0:36:44.01,0:36:47.68,Default,,0000,0000,0000,,And so remember your email will always\Neventually fill the buffers
Dialogue: 0,0:36:47.68,0:36:53.20,Default,,0000,0000,0000,,to full capacity and those large \Nbuffers will take a long time to clear.
Dialogue: 0,0:36:53.87,0:36:59.58,Default,,0000,0000,0000,,Any applications that require \Nreliability but also really benefit
Dialogue: 0,0:36:59.58,0:37:03.99,Default,,0000,0000,0000,,from low latency that \Nsay stock trading for example.
Dialogue: 0,0:37:03.99,0:37:06.90,Default,,0000,0000,0000,,They have an issue with the high latency
Dialogue: 0,0:37:07.44,0:37:10.27,Default,,0000,0000,0000,,that's caused by this buffered load
Dialogue: 0,0:37:10.47,0:37:18.32,Default,,0000,0000,0000,,so buffers have to be reasonably small to\Nmaintain a reasonably low network latency.
Dialogue: 0,0:37:18.60,0:37:22.66,Default,,0000,0000,0000,,So we can't just make buffers really\Nreally big that will cause problems
Dialogue: 0,0:37:22.71,0:37:32.82,Default,,0000,0000,0000,,for applications that you know rely \Non or benefit from lower latency.
Dialogue: 0,0:37:33.58,0:37:37.20,Default,,0000,0000,0000,,So we talked about (INAUDIBLE)\Nwhich has been
Dialogue: 0,0:37:37.20,0:37:41.55,Default,,0000,0000,0000,,the standard congestion control\Nmechanism for some time.
Dialogue: 0,0:37:42.07,0:37:43.95,Default,,0000,0000,0000,,It's still used by Windows.
Dialogue: 0,0:37:44.23,0:37:47.35,Default,,0000,0000,0000,,It was still used by Mac OS\Nuntil fairly recently.
Dialogue: 0,0:37:47.92,0:37:51.07,Default,,0000,0000,0000,,But actually dozens \Nperhaps hundreds
Dialogue: 0,0:37:51.07,0:37:57.95,Default,,0000,0000,0000,,including sort of research \Nresearch kind of algorithms
Dialogue: 0,0:37:57.95,0:38:00.51,Default,,0000,0000,0000,,that exist,\NLinux and Mac OS
Dialogue: 0,0:38:00.55,0:38:03.00,Default,,0000,0000,0000,,now use a different algorithm\Ncalled cubic.
Dialogue: 0,0:38:03.16,0:38:06.06,Default,,0000,0000,0000,,And there's also an algorithm called BBR,\Nit's been designed by Google
Dialogue: 0,0:38:06.06,0:38:10.26,Default,,0000,0000,0000,,in recent years,\Nit has created a bit of a hype
Dialogue: 0,0:38:10.59,0:38:13.00,Default,,0000,0000,0000,,Not all aim for maximum performance.
Dialogue: 0,0:38:13.26,0:38:18.45,Default,,0000,0000,0000,,So some might have slightly different \Naims and there's also algorithms
Dialogue: 0,0:38:18.48,0:38:22.59,Default,,0000,0000,0000,,that use estimates of network delay \Nas an indicator of congestion as well
Dialogue: 0,0:38:22.59,0:38:25.05,Default,,0000,0000,0000,,not just losses indicate of congestion
Dialogue: 0,0:38:25.08,0:38:28.61,Default,,0000,0000,0000,,but also estimates of network \Nlike for example BBR.
Dialogue: 0,0:38:29.07,0:38:33.93,Default,,0000,0000,0000,,And despite the fact that \NTCP is a fairly old protocol
Dialogue: 0,0:38:34.76,0:38:37.62,Default,,0000,0000,0000,,TCP congestion control is \Nstill a highly active
Dialogue: 0,0:38:37.62,0:38:40.77,Default,,0000,0000,0000,,research area in data \Ncommunications.
Dialogue: 0,0:38:42.48,0:38:48.22,Default,,0000,0000,0000,,There's also something called \Nactive queue management.
Dialogue: 0,0:38:48.22,0:38:57.04,Default,,0000,0000,0000,,So the idea is to improve things by \Nactually routers actively telling
Dialogue: 0,0:38:57.04,0:39:05.00,Default,,0000,0000,0000,,TTP senders that there is congestion \Nsort of if routers could tell senders
Dialogue: 0,0:39:05.13,0:39:09.59,Default,,0000,0000,0000,,and sort of some configure buffer \Nthat is when there's congestion then,
Dialogue: 0,0:39:09.59,0:39:17.36,Default,,0000,0000,0000,,senders could back off earlier and we \Ncould avoid the packet loss.
Dialogue: 0,0:39:17.47,0:39:20.93,Default,,0000,0000,0000,,So there are some algorithm \Nof active queue management
Dialogue: 0,0:39:21.08,0:39:24.48,Default,,0000,0000,0000,,and there is something called TCP\Nearly congestion notification.
Dialogue: 0,0:39:24.89,0:39:28.93,Default,,0000,0000,0000,,And the idea is that the route of \Nthe mock packets when the queue length
Dialogue: 0,0:39:28.93,0:39:32.01,Default,,0000,0000,0000,,or the estimate layers\Nabove computable threshold.
Dialogue: 0,0:39:32.45,0:39:35.18,Default,,0000,0000,0000,,And then the TTP receiver \Nwill echo those marks
Dialogue: 0,0:39:35.18,0:39:38.64,Default,,0000,0000,0000,,back to the sender \Nand the sender can reduce
Dialogue: 0,0:39:38.64,0:39:42.50,Default,,0000,0000,0000,,the congestion window before \Nwe actually get to that stage
Dialogue: 0,0:39:42.50,0:39:44.00,Default,,0000,0000,0000,,where we have packet loss.
Dialogue: 0,0:39:44.03,0:39:47.93,Default,,0000,0000,0000,,So using this mechanism will \Nactually improve performance.
Dialogue: 0,0:39:49.47,0:39:56.24,Default,,0000,0000,0000,,But it requires that routers \Nsupport this mechanism.
Dialogue: 0,0:39:56.28,0:40:01.68,Default,,0000,0000,0000,,And of course senders and receivers \Nmust also support the mechanism
Dialogue: 0,0:40:04.48,0:40:08.80,Default,,0000,0000,0000,,Active queue management can actually \Nimprove performance quite a bit
Dialogue: 0,0:40:08.80,0:40:12.61,Default,,0000,0000,0000,,but many people don't actually notice.
Dialogue: 0,0:40:12.64,0:40:16.03,Default,,0000,0000,0000,,So to illustrate that point,\NI created this little slide here.
Dialogue: 0,0:40:16.03,0:40:22.65,Default,,0000,0000,0000,,So we have the normal \Nsort of FIFO queues
Dialogue: 0,0:40:22.69,0:40:25.86,Default,,0000,0000,0000,,and also two graphs \Nappear for FIFO queues
Dialogue: 0,0:40:26.26,0:40:28.45,Default,,0000,0000,0000,,first in first out and then down here,
Dialogue: 0,0:40:28.45,0:40:32.86,Default,,0000,0000,0000,,those two graphs are for \Nan active queue management mechanism.
Dialogue: 0,0:40:32.86,0:40:35.37,Default,,0000,0000,0000,,called F Queue codal.
Dialogue: 0,0:40:35.72,0:40:38.00,Default,,0000,0000,0000,,This is from an experiment \Nwhere we have...
Dialogue: 0,0:40:38.85,0:40:42.11,Default,,0000,0000,0000,,when we look at the UpLink let's say
Dialogue: 0,0:40:42.41,0:40:45.56,Default,,0000,0000,0000,,the uplink from your home network \Nto the Internet
Dialogue: 0,0:40:45.56,0:40:48.00,Default,,0000,0000,0000,,and there's three traffic flows.
Dialogue: 0,0:40:48.02,0:40:51.61,Default,,0000,0000,0000,,There is a gaming flow based \Non UDP going upstream.
Dialogue: 0,0:40:51.62,0:40:56.67,Default,,0000,0000,0000,,That's the dark blue line here so those\Ntwo graphs are throughput graphs,
Dialogue: 0,0:40:56.67,0:41:00.95,Default,,0000,0000,0000,,so just write the throughput \Nof the three different traffic flows
Dialogue: 0,0:41:00.95,0:41:05.30,Default,,0000,0000,0000,,so that flow here is a game traffic \Nit's veryy constant sort of throughput
Dialogue: 0,0:41:05.30,0:41:11.56,Default,,0000,0000,0000,,and the other two traffic flows \Nare TCP connections.
Dialogue: 0,0:41:11.65,0:41:16.05,Default,,0000,0000,0000,,So the light brown here, that's the\Nthroughput of the TCP connections.
Dialogue: 0,0:41:16.05,0:41:18.54,Default,,0000,0000,0000,,And those two graphs in\Nthe right hand side here
Dialogue: 0,0:41:18.54,0:41:24.55,Default,,0000,0000,0000,,show the RTT that those traffic \Nflows experience.
Dialogue: 0,0:41:24.90,0:41:30.39,Default,,0000,0000,0000,,And the sort of fixed \Ndelay for this experiment
Dialogue: 0,0:41:30.39,0:41:36.16,Default,,0000,0000,0000,,was set to 100 milliseconds \Nof RTT and anything above
Dialogue: 0,0:41:36.17,0:41:39.97,Default,,0000,0000,0000,,100 milliseconds is added, \Nconstitutes delay added by
Dialogue: 0,0:41:39.97,0:41:44.59,Default,,0000,0000,0000,,queueing the packets inside \Nthe router and so you can see
Dialogue: 0,0:41:44.59,0:41:48.88,Default,,0000,0000,0000,,with our traditional sort of \Nfirst in first out strategy
Dialogue: 0,0:41:48.88,0:41:52.36,Default,,0000,0000,0000,,we'll get fairly high delays \Nand like all
Dialogue: 0,0:41:52.37,0:41:54.56,Default,,0000,0000,0000,,the three different traffic \Nflows experienced
Dialogue: 0,0:41:54.56,0:41:57.83,Default,,0000,0000,0000,,the same types of delays \Nand the like it's fairly high,
Dialogue: 0,0:41:57.83,0:42:00.64,Default,,0000,0000,0000,,so we almost reached \N300 milliseconds here
Dialogue: 0,0:42:01.19,0:42:04.86,Default,,0000,0000,0000,,much much higher than \Nthe sort of the base delay.
Dialogue: 0,0:42:05.84,0:42:11.15,Default,,0000,0000,0000,,So when we do the same type \Nof experiments but with F Queue codal
Dialogue: 0,0:42:11.15,0:42:15.74,Default,,0000,0000,0000,,to manage the queue then A you see \Nin the throughput graph here,
Dialogue: 0,0:42:15.74,0:42:21.19,Default,,0000,0000,0000,,we got a bit of more fairness \Nin the sharing here I suppose
Dialogue: 0,0:42:21.19,0:42:25.58,Default,,0000,0000,0000,,of the TCP flows closer to \Nthe fair share
Dialogue: 0,0:42:25.58,0:42:29.20,Default,,0000,0000,0000,,whereas here, that's a fair bit \Nof going up and down.
Dialogue: 0,0:42:29.63,0:42:34.22,Default,,0000,0000,0000,,And the other thing you can see while \None thing is quite hard to see
Dialogue: 0,0:42:34.22,0:42:37.73,Default,,0000,0000,0000,,but for the actual game traffic \Nhere the delay is really minimal.
Dialogue: 0,0:42:37.73,0:42:40.97,Default,,0000,0000,0000,,So the dark blue dots they \Nonly extend up to here.
Dialogue: 0,0:42:41.01,0:42:46.91,Default,,0000,0000,0000,,OK so we'll barely reach \N125 milliseconds for the game traffic
Dialogue: 0,0:42:46.91,0:42:50.44,Default,,0000,0000,0000,,which is of course very important \Nif you play first person shooter games
Dialogue: 0,0:42:50.44,0:42:58.49,Default,,0000,0000,0000,,and for the TCP flows we get a little bit \Nmore delay here but basically after that
Dialogue: 0,0:42:58.50,0:43:00.95,Default,,0000,0000,0000,,so slow start fair, well, \Nwe'll never really exceed
Dialogue: 0,0:43:01.03,0:43:08.09,Default,,0000,0000,0000,,200 milliseconds of delay so you \Ncan see the positive effect here
Dialogue: 0,0:43:08.09,0:43:12.65,Default,,0000,0000,0000,,will reduce delay and we'll get \Na fairer sharing here
Dialogue: 0,0:43:13.19,0:43:17.70,Default,,0000,0000,0000,,and that's actually home routers where\Nyou can you can turn this on
Dialogue: 0,0:43:17.70,0:43:21.81,Default,,0000,0000,0000,,so you can actually change from FIFO\Nto F Queue codal.
Dialogue: 0,0:43:21.88,0:43:27.59,Default,,0000,0000,0000,,so this is usually this \Nusually behind some
Dialogue: 0,0:43:27.59,0:43:30.06,Default,,0000,0000,0000,,of the quality of of \Nservice settings that
Dialogue: 0,0:43:30.14,0:43:32.03,Default,,0000,0000,0000,,you can do with your routers here.
Dialogue: 0,0:43:32.33,0:43:34.71,Default,,0000,0000,0000,,You can investigate and see \Nif your router supports it
Dialogue: 0,0:43:34.71,0:43:37.36,Default,,0000,0000,0000,,and you might actually get \Nbetter quality of service
Dialogue: 0,0:43:37.36,0:43:40.80,Default,,0000,0000,0000,,by turning those mechanisms on.
Dialogue: 0,0:43:42.28,0:43:45.37,Default,,0000,0000,0000,,Another mechanism that TCP \Nhas is CCP flow control
Dialogue: 0,0:43:46.24,0:43:48.64,Default,,0000,0000,0000,,it's very similar to \Ncongestion control but it's
Dialogue: 0,0:43:49.42,0:43:51.85,Default,,0000,0000,0000,,to prevent the sender from \Noverflowing the receiver
Dialogue: 0,0:43:52.42,0:43:54.97,Default,,0000,0000,0000,,instead of offering that \Nat the network bottleneck.
Dialogue: 0,0:43:55.90,0:44:00.55,Default,,0000,0000,0000,,So I think at the sender receiver \Nhaving vastly different performance
Dialogue: 0,0:44:00.55,0:44:06.19,Default,,0000,0000,0000,,for example a Netflix cache with \Na low cost smart TV.
Dialogue: 0,0:44:06.19,0:44:09.43,Default,,0000,0000,0000,,The way it works is the receiver \Nadvertise the receive window
Dialogue: 0,0:44:09.43,0:44:13.08,Default,,0000,0000,0000,,the number of bytes it will accept \Nbefore the next acknowledgement
Dialogue: 0,0:44:13.08,0:44:14.83,Default,,0000,0000,0000,,or window update.
Dialogue: 0,0:44:15.23,0:44:18.56,Default,,0000,0000,0000,,And then this is based on \Nthe windowing mechanism
Dialogue: 0,0:44:19.10,0:44:20.90,Default,,0000,0000,0000,,much like congestion control
Dialogue: 0,0:44:20.90,0:44:24.38,Default,,0000,0000,0000,,and overall the sender will be \Nrestricted to the minimum
Dialogue: 0,0:44:24.95,0:44:27.72,Default,,0000,0000,0000,,of the congestion window and \Nthe receive window of course
Dialogue: 0,0:44:27.94,0:44:31.34,Default,,0000,0000,0000,,So that's why we're \Nbasically trying to avoid
Dialogue: 0,0:44:32.03,0:44:36.36,Default,,0000,0000,0000,,the network bottleneck and the receiver.
Dialogue: 0,0:44:36.50,0:44:40.40,Default,,0000,0000,0000,,Alright and that's the basic \Ndata about the TCP protocol.
Dialogue: 0,0:44:40.40,0:44:45.86,Default,,0000,0000,0000,,Also the next couple of slides \Nwill discuss the other
Dialogue: 0,0:44:45.86,0:44:50.14,Default,,0000,0000,0000,,major transport protocol \Nthe UDP datagrams protocol and...
Dialogue: 0,0:44:50.30,0:44:54.14,Default,,0000,0000,0000,,Well as you will see here\NUDP is much simpler.
Dialogue: 0,0:44:54.14,0:44:58.42,Default,,0000,0000,0000,,So UDP is used when the data \Nmust arrive in a timely manner
Dialogue: 0,0:44:58.42,0:45:02.44,Default,,0000,0000,0000,,unlike TCP, \NUDP is connectionless protocol.
Dialogue: 0,0:45:02.47,0:45:05.96,Default,,0000,0000,0000,,So there's no connection set up,\Nconnection tear down,
Dialogue: 0,0:45:06.00,0:45:09.51,Default,,0000,0000,0000,,There's no notion of a \Nconnection with UDP.
Dialogue: 0,0:45:09.52,0:45:15.64,Default,,0000,0000,0000,,It's a best effort protocol and has\Nno equivalent to TCP acknowledgement.
Dialogue: 0,0:45:15.78,0:45:19.53,Default,,0000,0000,0000,,So it's not necessarily \Nless reliable but there's
Dialogue: 0,0:45:19.53,0:45:25.53,Default,,0000,0000,0000,,no reliability built in, \Nthere's no reliability guaranteed.
Dialogue: 0,0:45:25.59,0:45:29.70,Default,,0000,0000,0000,,If there is packet loss \Nthen UDP datagrams
Dialogue: 0,0:45:29.70,0:45:35.28,Default,,0000,0000,0000,,they're just lost and there's no \Nre transmitting mechanism.
Dialogue: 0,0:45:35.28,0:45:40.53,Default,,0000,0000,0000,,Also if datagrams are reordered in \Nthe network at the receiver
Dialogue: 0,0:45:40.53,0:45:45.14,Default,,0000,0000,0000,,there's no attempt to reorder those \Ndatagrams back into the original order.
Dialogue: 0,0:45:45.21,0:45:48.01,Default,,0000,0000,0000,,It also has no congestion or flow control
Dialogue: 0,0:45:48.76,0:45:53.31,Default,,0000,0000,0000,,but on the positive side with UDP\Nwe very low pay packet overhead
Dialogue: 0,0:45:53.31,0:45:57.75,Default,,0000,0000,0000,,so you have a much smaller \Nand simpler packet header.
Dialogue: 0,0:45:58.00,0:46:02.23,Default,,0000,0000,0000,,The one thing that UDP has in common\Nwith TCP, is port number.
Dialogue: 0,0:46:02.23,0:46:07.39,Default,,0000,0000,0000,,So UDP has exactly the same sort of \Nport numbers
Dialogue: 0,0:46:07.39,0:46:11.31,Default,,0000,0000,0000,,that TCP has, so same thing\Nand then you will see
Dialogue: 0,0:46:11.31,0:46:15.27,Default,,0000,0000,0000,,it's got the same port number,\Nfields and header as I'll show you that
Dialogue: 0,0:46:15.27,0:46:17.80,Default,,0000,0000,0000,,in aslide or two.
Dialogue: 0,0:46:17.80,0:46:20.89,Default,,0000,0000,0000,,So yeah, to stress the point\Nabout UDP right.
Dialogue: 0,0:46:20.89,0:46:24.63,Default,,0000,0000,0000,,Reliability or lack thereof.
Dialogue: 0,0:46:24.70,0:46:28.97,Default,,0000,0000,0000,,So UDP will not reassemble data packets\Nto the original order
Dialogue: 0,0:46:28.97,0:46:33.70,Default,,0000,0000,0000,,and it will not resend lost datagrams \Nbecause it's connection is unreliable.
Dialogue: 0,0:46:33.70,0:46:37.63,Default,,0000,0000,0000,,So this is sort of the same \Nthat we looked at before
Dialogue: 0,0:46:37.63,0:46:41.26,Default,,0000,0000,0000,,with TCP where datagrams \Ncan take different
Dialogue: 0,0:46:41.65,0:46:46.00,Default,,0000,0000,0000,,paths through the network \Nand with UDP if the order
Dialogue: 0,0:46:46.00,0:46:48.25,Default,,0000,0000,0000,,is jumbled up because \Nof its different parts.
Dialogue: 0,0:46:48.25,0:46:52.45,Default,,0000,0000,0000,,Well then the datagrams will be \Ndelivered in this jumbled up order
Dialogue: 0,0:46:52.45,0:46:59.01,Default,,0000,0000,0000,,to the application and then the\Napplication has to sort that issue out.
Dialogue: 0,0:46:59.59,0:47:01.66,Default,,0000,0000,0000,,So why would an application actually use
Dialogue: 0,0:47:01.66,0:47:04.81,Default,,0000,0000,0000,,this kind of unreliable \Ntransport protocol.
Dialogue: 0,0:47:04.81,0:47:07.37,Default,,0000,0000,0000,,Well there's a couple of cases where
Dialogue: 0,0:47:07.37,0:47:11.44,Default,,0000,0000,0000,,we prefer UDP over TCP. \NAnd the first case is because
Dialogue: 0,0:47:11.77,0:47:16.70,Default,,0000,0000,0000,,resending data is useless and we \Nwant to avoid any additional delay.
Dialogue: 0,0:47:16.70,0:47:19.58,Default,,0000,0000,0000,,So if you think about \Nteleconferencing
Dialogue: 0,0:47:19.58,0:47:26.74,Default,,0000,0000,0000,,something like Skype or Discord \Nor whatever additional delay
Dialogue: 0,0:47:26.74,0:47:30.13,Default,,0000,0000,0000,,for re transmissions are \Nmore annoying than
Dialogue: 0,0:47:30.13,0:47:34.15,Default,,0000,0000,0000,,the drop outs in the voice \Nsimilar online games.
Dialogue: 0,0:47:34.15,0:47:37.33,Default,,0000,0000,0000,,There's no point in resending \Npackets after some actions
Dialogue: 0,0:47:37.93,0:47:42.73,Default,,0000,0000,0000,,because you don't \Nreally want a lag game.
Dialogue: 0,0:47:42.74,0:47:47.59,Default,,0000,0000,0000,,So you'd rather take into account \Nthat there maybe packet loss
Dialogue: 0,0:47:47.59,0:47:51.52,Default,,0000,0000,0000,,and for example \Nuse some redundancy.
Dialogue: 0,0:47:51.68,0:47:56.98,Default,,0000,0000,0000,,That's what many games use,\Nso send data across multiple packets
Dialogue: 0,0:47:56.98,0:47:59.42,Default,,0000,0000,0000,,so it doesn't matter if one is lost.
Dialogue: 0,0:47:59.42,0:48:02.33,Default,,0000,0000,0000,,But we don't add any extra delay because
Dialogue: 0,0:48:02.73,0:48:06.51,Default,,0000,0000,0000,,on games that might be \Nquite delay sensitive
Dialogue: 0,0:48:06.51,0:48:11.42,Default,,0000,0000,0000,,if you think about first person \Nshooter games or similar games.
Dialogue: 0,0:48:11.69,0:48:17.23,Default,,0000,0000,0000,,So that's one reason we want \Nto keep the delay sort of
Dialogue: 0,0:48:17.32,0:48:23.09,Default,,0000,0000,0000,,really short and we don't need \Nto recent data.
Dialogue: 0,0:48:24.05,0:48:30.86,Default,,0000,0000,0000,,Second case is we want to avoid\Nthe complexities of TCP
Dialogue: 0,0:48:30.86,0:48:33.73,Default,,0000,0000,0000,,and the omits of TCP.
Dialogue: 0,0:48:33.73,0:48:38.35,Default,,0000,0000,0000,,So a full TCP implementation \Nis very complex and it may
Dialogue: 0,0:48:38.35,0:48:42.76,Default,,0000,0000,0000,,be too complex for this human based\NLCP or the RAM.
Dialogue: 0,0:48:44.01,0:48:49.70,Default,,0000,0000,0000,,And the application can implement \Na simple acknowledgement scheme
Dialogue: 0,0:48:49.70,0:48:53.18,Default,,0000,0000,0000,,on top of UDP to transport \Nthe item that's required.
Dialogue: 0,0:48:53.69,0:48:57.75,Default,,0000,0000,0000,,An example of such a protocols, \Nit should be your file transfer protocols.
Dialogue: 0,0:48:57.75,0:48:58.50,Default,,0000,0000,0000,,the FTP.
Dialogue: 0,0:48:59.33,0:49:06.89,Default,,0000,0000,0000,,It's basically a simple sort of reliable \Nprotocol that sits on top of UDP.
Dialogue: 0,0:49:06.92,0:49:11.98,Default,,0000,0000,0000,,but it's simpler than \Na full TCP implementation
Dialogue: 0,0:49:14.59,0:49:18.94,Default,,0000,0000,0000,,And the third case where \Nyou might want to use UDP
Dialogue: 0,0:49:18.94,0:49:22.78,Default,,0000,0000,0000,,is because you want to avoid \Nthe setup and the tear down.
Dialogue: 0,0:49:22.78,0:49:27.25,Default,,0000,0000,0000,,of connections \Nthat we have in TCP
Dialogue: 0,0:49:27.25,0:49:29.83,Default,,0000,0000,0000,,because setting up \Nand tearing down TCP connections
Dialogue: 0,0:49:29.83,0:49:32.18,Default,,0000,0000,0000,,requires a minimum of six packets.
Dialogue: 0,0:49:32.18,0:49:37.81,Default,,0000,0000,0000,,OK that's a fair bit of sort of bandwidth,\Nit might be unnecessary
Dialogue: 0,0:49:37.89,0:49:45.09,Default,,0000,0000,0000,,and also setting up connections requires\Nthe server to be in state of connections
Dialogue: 0,0:49:45.15,0:49:51.79,Default,,0000,0000,0000,,so that uses view CPU and also RAM\Nand you want to avoid that
Dialogue: 0,0:49:51.79,0:49:57.29,Default,,0000,0000,0000,,If we have frequent so short \Nmessage exchanges
Dialogue: 0,0:49:57.29,0:50:00.77,Default,,0000,0000,0000,,it's actually more efficient \Nand cheaper in terms of bandwidth.
Dialogue: 0,0:50:00.77,0:50:06.00,Default,,0000,0000,0000,,So resources to use UDP and a prime\Nexample of this is DNS lookups.
Dialogue: 0,0:50:07.53,0:50:09.85,Default,,0000,0000,0000,,So with DNS we have serverss that \Nhave to deal
Dialogue: 0,0:50:09.85,0:50:13.02,Default,,0000,0000,0000,,with thousands of requests per second.
Dialogue: 0,0:50:13.02,0:50:16.46,Default,,0000,0000,0000,,And the DNS requests plus \Nreplies usually only two packets
Dialogue: 0,0:50:16.46,0:50:21.15,Default,,0000,0000,0000,,so one packet for the request \Nand then there's one packet for the reply
Dialogue: 0,0:50:21.18,0:50:26.33,Default,,0000,0000,0000,,and that's a quarter of the packets\Nthat we would need with TCP
Dialogue: 0,0:50:26.34,0:50:30.45,Default,,0000,0000,0000,,So remember we'll not only have \Nthose two packets but an additional
Dialogue: 0,0:50:30.45,0:50:34.64,Default,,0000,0000,0000,,six packets for setting up a \Nconnection and then tearing it down.
Dialogue: 0,0:50:34.80,0:50:38.97,Default,,0000,0000,0000,,Plus if we have those short message\Nexchanges then flow congestion
Dialogue: 0,0:50:39.08,0:50:42.11,Default,,0000,0000,0000,,so flow control and congestion control
Dialogue: 0,0:50:42.15,0:50:43.98,Default,,0000,0000,0000,,they're really useless \Nfor these short flows
Dialogue: 0,0:50:43.98,0:50:45.99,Default,,0000,0000,0000,,I mean that that they don't work.
Dialogue: 0,0:50:45.99,0:50:50.29,Default,,0000,0000,0000,,They only work for so longer term flows.
Dialogue: 0,0:50:50.50,0:50:55.29,Default,,0000,0000,0000,,And well last but not least if you \Nuse UDP we can actually implement
Dialogue: 0,0:50:55.31,0:51:00.21,Default,,0000,0000,0000,,a reliable transport protocol on top \Nof UDP without having to change
Dialogue: 0,0:51:00.69,0:51:06.81,Default,,0000,0000,0000,,the operating system kernel because \Nremember the protocols stack up to
Dialogue: 0,0:51:06.81,0:51:10.65,Default,,0000,0000,0000,,the transport layer actually implemented \Nin the operating system kernel.
Dialogue: 0,0:51:11.43,0:51:16.14,Default,,0000,0000,0000,,And it's harder to make changes \Nthere and it's impossible
Dialogue: 0,0:51:16.59,0:51:20.79,Default,,0000,0000,0000,,if the operating system is closed source\Nso for example like Mac OS and windows.
Dialogue: 0,0:51:20.79,0:51:25.20,Default,,0000,0000,0000,,So there is a protocol called Quick.\NIt's a new transport protocol,
Dialogue: 0,0:51:25.20,0:51:26.88,Default,,0000,0000,0000,,it'ss developed \Nat Google to optimise
Dialogue: 0,0:51:27.48,0:51:31.59,Default,,0000,0000,0000,,HTTP performance and to \Nyou most likely use it
Dialogue: 0,0:51:31.59,0:51:35.31,Default,,0000,0000,0000,,every day if you actually \Nuse the Chrome browser.
Dialogue: 0,0:51:35.46,0:51:39.12,Default,,0000,0000,0000,,And so the problem for Google \Nwas they wanted to do
Dialogue: 0,0:51:40.16,0:51:46.40,Default,,0000,0000,0000,,an improved protocol to improve \Nperformance but pushing Quick
Dialogue: 0,0:51:46.40,0:51:50.07,Default,,0000,0000,0000,,into the operating system \Nkernels of all sorts of
Dialogue: 0,0:51:51.21,0:51:57.39,Default,,0000,0000,0000,,clients that would be very \Ndifficult for Google to do.
Dialogue: 0,0:51:57.72,0:52:02.01,Default,,0000,0000,0000,,But they own the Chrome browser \Nso they can very easily
Dialogue: 0,0:52:02.01,0:52:06.48,Default,,0000,0000,0000,,implement a transport protocol on \Ntop of UDP inside the browser.
Dialogue: 0,0:52:06.48,0:52:11.50,Default,,0000,0000,0000,,So that's why they chose that avenue\Nof course in terms of resources
Dialogue: 0,0:52:11.50,0:52:13.83,Default,,0000,0000,0000,,the implementation inside \Nthe browser might
Dialogue: 0,0:52:14.07,0:52:19.36,Default,,0000,0000,0000,,take up a few more cycles\Nin terms of CPU.
Dialogue: 0,0:52:19.57,0:52:22.84,Default,,0000,0000,0000,,But the good thing for Google \Nis they fully control that
Dialogue: 0,0:52:22.84,0:52:25.75,Default,,0000,0000,0000,,environment that can push \Nupdates at any point in time
Dialogue: 0,0:52:26.41,0:52:29.38,Default,,0000,0000,0000,,and they just have to update \Nchrome rather than having to
Dialogue: 0,0:52:29.38,0:52:34.84,Default,,0000,0000,0000,,update lots and lots of different \Noperating systems.
Dialogue: 0,0:52:34.84,0:52:39.49,Default,,0000,0000,0000,,Almost at the end so just have a quick \Nlook at the UDP and TCP protocol
Dialogue: 0,0:52:39.49,0:52:42.91,Default,,0000,0000,0000,,headers here so you can \Nsee that the TTP protocol header
Dialogue: 0,0:52:42.91,0:52:45.45,Default,,0000,0000,0000,,is much bigger \Nobviously because we have much
Dialogue: 0,0:52:45.45,0:52:49.50,Default,,0000,0000,0000,,more functionality in TCP \Nand the UDP head down here.
Dialogue: 0,0:52:49.92,0:52:54.18,Default,,0000,0000,0000,,You can see that both headers \Nhave the source port
Dialogue: 0,0:52:54.24,0:52:59.24,Default,,0000,0000,0000,,and the destination port as \Nthe first two header fields and then
Dialogue: 0,0:52:59.24,0:53:04.17,Default,,0000,0000,0000,,the UDP hasn't got much else besides \Nthe length and the checksum
Dialogue: 0,0:53:05.02,0:53:07.57,Default,,0000,0000,0000,,but TCP of course \Nwe have the sequence numbers.
Dialogue: 0,0:53:07.59,0:53:12.51,Default,,0000,0000,0000,,We have the acknowledgement numbers \Nwe have the window size
Dialogue: 0,0:53:12.51,0:53:17.52,Default,,0000,0000,0000,,and a bunch of flex to deal \Nwith all the threeway handshake
Dialogue: 0,0:53:17.52,0:53:20.99,Default,,0000,0000,0000,,tear downs and so on.
Dialogue: 0,0:53:20.99,0:53:25.78,Default,,0000,0000,0000,,So let's discuss TCP by this UDP.
Dialogue: 0,0:53:25.81,0:53:28.07,Default,,0000,0000,0000,,Well neither protocol is better.
Dialogue: 0,0:53:28.09,0:53:31.18,Default,,0000,0000,0000,,It's just what's appropriate \Nfor the application.
Dialogue: 0,0:53:32.17,0:53:37.26,Default,,0000,0000,0000,,So if you're an application developer\Nyou must decide what to use.
Dialogue: 0,0:53:40.95,0:53:45.61,Default,,0000,0000,0000,,If your application, you know,\Nrequires fast protocol, low overheads,
Dialogue: 0,0:53:45.64,0:53:48.72,Default,,0000,0000,0000,,you don't need acknowledgments \Nyou don't need to reset lost data
Dialogue: 0,0:53:48.72,0:53:51.85,Default,,0000,0000,0000,,and you want to deliver data \Nas fast as it arrives
Dialogue: 0,0:53:51.85,0:53:54.34,Default,,0000,0000,0000,,for example for things like IP tuner
Dialogue: 0,0:53:54.34,0:53:58.28,Default,,0000,0000,0000,,for streaming rather \Nthan UDP is your choice.
Dialogue: 0,0:53:58.35,0:54:04.96,Default,,0000,0000,0000,,If you need reliability you'd \Nacknowledgements reending of those data
Dialogue: 0,0:54:04.96,0:54:07.63,Default,,0000,0000,0000,,and data needs to be \Ndelivered to the application.
Dialogue: 0,0:54:07.65,0:54:11.40,Default,,0000,0000,0000,,in the order it was sent \Nwhich is the case for example
Dialogue: 0,0:54:11.40,0:54:13.75,Default,,0000,0000,0000,,for applications \Nlike email or web.
Dialogue: 0,0:54:13.80,0:54:22.05,Default,,0000,0000,0000,,Then you should use TCP of course. \NA little a homework for you
Dialogue: 0,0:54:22.05,0:54:29.11,Default,,0000,0000,0000,,the following Cisco or network activity \Nlet me just quickly switch to that.
Dialogue: 0,0:54:29.17,0:54:40.82,Default,,0000,0000,0000,,So it's basically activity \Nto select
Dialogue: 0,0:54:40.82,0:54:45.55,Default,,0000,0000,0000,,the right transport protocol \Nfor a number of different applications.
Dialogue: 0,0:54:45.55,0:54:49.17,Default,,0000,0000,0000,,So over here have all \Nthose applications HDP
Dialogue: 0,0:54:49.24,0:54:54.00,Default,,0000,0000,0000,,telnet FTP and we all discussed\Na couple of those in the first lecture
Dialogue: 0,0:54:54.00,0:54:58.99,Default,,0000,0000,0000,,and you basically \Nhave to drag those boxes over here
Dialogue: 0,0:54:58.99,0:55:04.23,Default,,0000,0000,0000,,to indicate where the something \Nis either TCP or UDP or both.
Dialogue: 0,0:55:04.66,0:55:07.10,Default,,0000,0000,0000,,So one example HDP.
Dialogue: 0,0:55:07.44,0:55:09.52,Default,,0000,0000,0000,,We discussed that uses TCP, right.
Dialogue: 0,0:55:09.52,0:55:11.47,Default,,0000,0000,0000,,And you can check your answers.\NThat's correct.
Dialogue: 0,0:55:13.18,0:55:19.54,Default,,0000,0000,0000,,Well I'll leave the rest \Nfor you to do at home.
Dialogue: 0,0:55:19.55,0:55:25.75,Default,,0000,0000,0000,,And I will conclude lecture as \Nmuch of lecture objectives
Dialogue: 0,0:55:25.75,0:55:31.49,Default,,0000,0000,0000,,and you should be able to describe\Na number of things
Dialogue: 0,0:55:31.49,0:55:34.43,Default,,0000,0000,0000,,I won't go through all these\Nlecture objectives in detail
Dialogue: 0,0:55:34.43,0:55:39.24,Default,,0000,0000,0000,,so just read all of those \Nand make sure you understand
Dialogue: 0,0:55:39.24,0:55:44.38,Default,,0000,0000,0000,,all those concepts and you \Ncan describe those concepts then...
Dialogue: 0,0:55:45.04,0:55:47.92,Default,,0000,0000,0000,,Well today's lecture we looked at \Nthe application presentation,
Dialogue: 0,0:55:47.92,0:55:53.56,Default,,0000,0000,0000,,such layers and the two major \Narchitect socommunications.
Dialogue: 0,0:55:53.56,0:55:57.05,Default,,0000,0000,0000,,And we also looked at the transport layer
Dialogue: 0,0:55:57.05,0:56:01.50,Default,,0000,0000,0000,,and the two main transport layer \Nprotocols, TCP and UDP.
Dialogue: 0,0:56:01.50,0:56:07.47,Default,,0000,0000,0000,,The readings for this week \Nintroduction to the chapters 9 and 10.
Dialogue: 0,0:56:07.48,0:56:11.01,Default,,0000,0000,0000,,And don't forget participation quiz.
Dialogue: 0,0:56:11.17,0:56:18.40,Default,,0000,0000,0000,,One is to this Sunday and in the lapse \Nin the second week
Dialogue: 0,0:56:18.40,0:56:22.11,Default,,0000,0000,0000,,we'll examining some network traffic \Nusing a tool called Bioshock
Dialogue: 0,0:56:22.18,0:56:27.42,Default,,0000,0000,0000,,so we look at actual DNS \Npackets and it's a three way handshake
Dialogue: 0,0:56:27.42,0:56:32.35,Default,,0000,0000,0000,,and how those things \Nactually look on the web.
Dialogue: 0,0:56:32.62,0:56:38.76,Default,,0000,0000,0000,,Oh well we'll look at those \Nthings flash up.
Dialogue: 0,0:56:38.76,0:56:44.67,Default,,0000,0000,0000,,And then the next week we will continue \Ndescending down the old same model.
Dialogue: 0,0:56:44.88,0:56:48.69,Default,,0000,0000,0000,,And so we'll talk about the network \NLAN next week.
Dialogue: 0,0:56:48.69,0:56:53.72,Default,,0000,0000,0000,,Specifically you'll look at IP addressing \Nand something called subnetting
Dialogue: 0,0:56:54.72,0:57:00.24,Default,,0000,0000,0000,,And we will start discussing the role\Nof routers in data communications.
Dialogue: 0,0:57:01.83,0:57:06.60,Default,,0000,0000,0000,,Well this is an online lecture \Nso you don't really sort of
Dialogue: 0,0:57:06.60,0:57:09.63,Default,,0000,0000,0000,,bring pen and paper because \NI assume you probably
Dialogue: 0,0:57:09.63,0:57:12.54,Default,,0000,0000,0000,,have a pen and paper wherever \Nyou're watching this lecture
Dialogue: 0,0:57:12.58,0:57:16.89,Default,,0000,0000,0000,,but you have some pen \Nand paper ready for exercise.
Dialogue: 0,0:57:17.85,0:57:19.65,Default,,0000,0000,0000,,That's it for me for this week.
Dialogue: 0,0:57:19.65,0:57:21.50,Default,,0000,0000,0000,,I'll see you next week's lecture.