>> [music] Good day viewers. In this segment I'll provide you with an introduction to the transport layer. But first, congratulations are in order. This diagram shows where we are in the course. And you can see that we've gone through the physical, link, and network layers, and now we're starting on the transport layer. The transport layer builds on the services of the network. And it delivers data across the network to applications. With different kinds of reliability or quality, depending on the transport service model. So here are a couple of slides just to recall where we are with protocols in general. This diagram shows two hosts communicating across a network with a single router and you can ignore all of the details of the protocols. They happen to be TCI IP and so forth. The point I want to make is that TCP, the transport layer, is communicating information. From host to host across the network. And this is the first time we've reached a layer where all of the information that's sent by it is not examined by devices inside the network. Or at least it shouldn't be. That wasn't the case with the network link in physical layer. Where intermediate systems, switches and routers, handled all of the information there. The transport layer is really using the network simply to get information between hosts. And we can also provide just a brief review in terms of data units. The name for message, at the transport level is a segment. And you can see here that segments, here's a They have transport control information like a TCP header, as well as a payload. The payload is application data that's carried across the network. The segment itself is carried within a packet, the network layer, and within a frame like a link layer. Okay, so I'm going to spend most of this segment talking about the different kinds of transport services that a transport layer might offer to its user, an application. Now, there are many different transport services you could imagine. The axis I'm going to use to classify them here are the ones that we use in the internet. A transport service could provide either reliable or unreliable. Transport. By reliable we mean if you send it, it will be delivered to the other side. Unreliable package can be lost in the network and this will be exposed to the transport user. Packets can still be lost in the network with a reliable service module. It's just the transport layer takes care of fixing this so the transport layer doesn't see a loss. So that was this top access and you can also see distinction in the unit of dan Data that's transferred. We might transfer individual messages, sort of like a post office model, or a, an infinite stream of bytes. That's the bytestream model. Now in the internet, we really provide two kinds of service for applications to use, two transport services. The common one you've probably heard of is TCP. Tcp is actually the protocol that implements one of the services. The service itself. Is a stream service. It's a reliable byte stream, a bi-direction reliable byte stream between applications. The other service that the Internet provides is a datagram model where you send messages. That service is implemented by UDP. Okay, let's just compare some of the features of these two different transport services, to get a little bit of a feeling for how they differ. Through what different kinds of services you could get depending on what the transport layer does for you. So on the left here we have TCP in this table, and you can see that TCP, well, it tend to information reliably. And so there are, there are many features that are related to reliability. Connections have to be setup. The bytes then are delivered reliably, meaning. Essentially that they delivered once and in the same order that they were send. Actually ordering in reliability is somewhat separate or we get both of them here. There is also since its a byte stream its in arbitrary content length model considers many bytes as you like, they will have to be divided into packets of segments inside the network but that's the transport layer's business. At the other side you receive messages as if they came in on an infinite byte stream. The transport layer it, it would TCP also prpvides flow control to match sender to the receiver capabilities. We haven't seen any of this yet. We're going to in the future. So I don't expect you to kow what flow control is yet nor congestin contorl. That's going to be a mechanism that matches the sender to the Networks capabilities in terms of its bandwidth. So you can see here TCP is really quite a full featured protocol. It does a lot on top of the network player to provide a service for applications. On the other hand UPD on the left side sorry on the right side of this table is really just a glorified packet transport. It does very little over IP. You've seen Datagrams, well they are really like packets. The messages, just like the post office, they can be lost and re-ordered. Somewhat like the personal service, they can be duplicated in networks, you can send one copy and two could come out. It's a little odd but that could happen. There is a limited message size because these are. Like packets. These datagrams. And you can send them at any time. Now this might sound good, but essentially here I'm saying that the transport service provides you no guidance on when its a good time to send. In terms of the receiver being able to handle those messages, or the network being able to deliver them. Tcp helps us with those tasks. So this right hand column, you can also see that i-, if I wrote down the capabilities for packets they would be very much like this. So here we see a bit of a dichotomy between TCP and UDP. You either get basically nothing bit IP or the whole kitchen sink in terms of features. Okay let me go on and talk more about the, the, the interface between the transport layer and the application layer which is using it as a service. We've actually seen this interface before. It's our good old sockets API. Now a sockets provided the simple abstraction for the socket to use the network. Before we talked about the network API. They're really allowing applications to use the network. But now the vicinity and you can see they're really providing a need to face to a transport layer service. Sockets are used to write all of the different internet applications you see out there. The socket API supports both of these kinds of internet transport services but the streams and the datagrams. That we just saw. When we looked at sockets before, we only looked at the, stream model. And you might have also seen this. We call this the connection-oriented, or a connection-oriented transport. And datagrams are connectionless. Just different names for some of those kinds of services. A little bit more about the sockets if you recall one of the key addressing attributes in the socket model is ports. Ports are, are where applications attach to the transport layer and sockets will sort these different. Ports are what let, is what lets multiple different applications use the same transport layer instance on a given machine. So we can multiplex the network between different applications. You can see here two applications, one and two, using different sockets and ports that's the addressing to attach the, to the transport layer. Here with the API again for sockets. Again we went through this a logn time ago when we did an introduction to the course. So I'm not going to provide you with an example of using this yet. Uim, I'll just point out here is the table. Now you know that it's the same kind of API that's used for both sockets and datagrams. It turns out, however, that these three calls here listen, Accepting connect you only need them for streams because this is all about setting up the connection. Datagrams are connection less. So you don't need to establish any connection before you use them. Similarly for send and receive, the with the streams we simply use send and receive. Just send the information across the network and receive it at the others side. With our datagrams, slightly different forms are used. Send to and receive from. This is because if you have no connection and you want to send the information, the missing parameter you'd need to specify is who to send it to. And with, with a, a datagram model you can actually send datagrams to many different receivers without having to set up any different connection between them over the same socket. Similarly receive Uses a phone code received from. And that provides information about who sent the datagram to you since many different senders could have sent that datagram that could be received on your port in a datagram model. Let's talk a little bit more about ports, and that will round out the service API that the transport layer provides in the internet applications. So we say that there are ports, these are these sixteen bit identifiers. Which, at which provide a addressing, for applications to use. Actually, it turns out, that in an application process, which is running on machine, is identified by the TUPL of the IP address, so that sort of tells you the machine the protocols, since this could be TCP and UDP, and they share the same port space, and the port number itself. Now you could simply think of a port, even though it's a 16 bit number, as representing a numbered mailbox. Applications can lease those mailboxes to use the services of the transport layer. Just like you might get a mailbox in a post office to use the postal system. In, in this case not only would you get things delivered to it, but that's where you put things in when you want them sent across the network. Clients and servers use ports slightly differently. Servers often bind to what are called well-known ports. These are ports below 1024. The naming is not quite accurate. Really, these ports are ports which require administrative privileges. To use. The idea here is that since you need to know the port to contact someone, servers are going to sit on one long port, they'll bind to one long port, so you'll know how to find the server. On the other hand, clients can use any old port as long as they tell the server who they contact what port they're sitting on, on the other machine, the server will be able to reply back to them. So clients are assigned what are called ephemeral ports, and you can ask the OS for a new port and it will pick one for you that's convenient for you to use temporarily. This table shows some of the well known ports. You're probably with some of them. So these are ports that servers would use so that a transport peer across the network would be able to open a connection. To the server, the most common one here that you'd be familiar with I bet, is port eighteen that's used for the HTTP protocol for web traffic. Some of you might also have heard of port four, four three, that's used, used when we use HTTPS, a secure version of HTTP. And there are many other ports on the table, I won't go through them but they're, they provide different kinds of ways to access your mail printers, our remote systems move falls around and so forth. What, what was the different ways we used the internet? Well that's all I want to say about the transport service, its provided to higher layer applications. In the coming segments we'll talk more about the implementation of that service inside the transport layer. So we've covered the service models here. That's all done. And when we look inside the transport layer, we now see all sorts of machinery. Most of it's going to be related to how TCP works. It's sliding window and how time outs are used to provide reliability. How connections are set up. It's making it's own flow controller and so forth. There is one big part of TCP however theirs a transport layer service that I'm going to defer until later. And that is congestion control, shown here in grey. Congestion control is about matching the, The transport rate at the edges of the network to the capabilities within the network, depending on the traffic. That's a major subject in itself and we'll get to that later. First we'll go through all of this other material on the transport layer. So, let's go for it.