§3.1Introduction and Transport-Layer Services

Transport layer Kurose & Ross pp. 182–186 · ~19 min read

  • logical communication
  • best-effort service

Where you are

  • Application layer
  • Transport layer you are here
  • Network layer
  • Link layer
  • Physical layer

The transport layer takes the network’s ability to move data between two machines. It turns that into the ability to move data between two running programs, using nothing but software at the two ends.

Words you will meet

  • Logical communication — the illusion that two programs are joined directly, however far apart they really are.
  • Best-effort service — the network tries to deliver each packet and promises nothing about the result.
  • Segment — the transport-layer packet: a chunk of the application’s message plus a transport header.
  • Datagram — the network-layer packet, which carries a segment inside it.
  • Service model — the list of promises a protocol makes to whatever is using it.

Why this matters

Chapter 2 spent a hundred pages asking applications what they want. It found that they want reliable delivery, and that some also want a minimum throughput or a maximum delay. Then it said the Internet offers two protocols, TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) , and moved on.

This chapter is the answer to how. Before any of it makes sense, though, you need one boundary drawn clearly: what the layer below already provides, and what the transport layer therefore has to build for itself. That boundary is this section, and getting it wrong makes the rest of the chapter feel arbitrary.

Between processes, not between machines

A transport-layer protocol provides logical communication between application processes running on different hosts. “Logical” is doing real work in that sentence. From the application’s point of view it is as if the two hosts were connected directly by a wire. In reality they may be on opposite sides of the planet. A dozen routers and several kinds of link — copper, fibre, radio — may lie between them, and the application never learns any of it.

Here is what actually happens. On the sending side, the transport layer takes the messages it receives from the application process, possibly breaks them into smaller chunks, and adds a transport-layer header to each chunk. The result is a segment . The transport layer hands the segment to the network layer, which encapsulates it inside a datagram and sends it towards the destination. On the receiving side the network layer pulls the segment back out and passes it up, and the transport layer makes the data available to the receiving application.

Figure 3.1 — the transport header is written once and read once
1 / 20
Lin’s laptopApplicationTransportNetworkLinkPhysicalaccess ISP routernot implementednot implementedNetworkLinkPhysicalglobal ISP routernot implementednot implementedNetworkLinkPhysicalwww.example.eduApplicationTransportNetworkLinkPhysicalthe packet at this moment:GET /index.htmlmessage

Lin’s laptop · Application The application has a message to send. At this point it is just data — nothing has been added to it yet.

Scrub through it. Every router shows an empty dashed box where the transport layer would be: the segment passes through untouched, and nothing in the middle of the network is allowed to look inside it.

Read all 20 steps as text
  1. Lin’s laptop · Application [GET /index.html]The application has a message to send. At this point it is just data — nothing has been added to it yet.
  2. Lin’s laptop · Transport [Ht | GET /index.html]The transport layer puts its header Ht in front. Everything below now treats the message as an opaque payload. This is a segment.
  3. Lin’s laptop · Network [Hn | Ht | GET /index.html]The network layer adds Hn, carrying the addresses of the two hosts. This is a datagram.
  4. Lin’s laptop · Link [Hl | Hn | Ht | GET /index.html]The link layer adds Hl, which describes how to cross this one link. This is a frame.
  5. Lin’s laptop · Physical [Hl | Hn | Ht | GET /index.html]The physical layer puts the individual bits of the frame onto the medium.
  6. access ISP router · Physical [Hl | Hn | Ht | GET /index.html]The bits arrive and are reassembled into a frame.
  7. access ISP router · Link [Hn | Ht | GET /index.html]The old link header is removed and discarded. It described the link the frame just crossed, and that link is behind us now.
  8. access ISP router · Network [Ht | GET /index.html]The router reads the destination address in Hn and chooses the outgoing link. It stops here: it does not implement the transport layer, so Ht means nothing to it.
  9. access ISP router · Link [Hl | Ht | GET /index.html]A brand-new link header is added for the next link. It may be a completely different link technology — Ethernet here, WiFi next — and the header changes to match.
  10. access ISP router · Physical [Hl | Ht | GET /index.html]The frame goes out onto the next link as bits.
  11. global ISP router · Physical [Hl | Hn | Ht | GET /index.html]The bits arrive and are reassembled into a frame.
  12. global ISP router · Link [Hn | Ht | GET /index.html]The old link header is removed and discarded. It described the link the frame just crossed, and that link is behind us now.
  13. global ISP router · Network [Ht | GET /index.html]The router reads the destination address in Hn and chooses the outgoing link. It stops here: it does not implement the transport layer, so Ht means nothing to it.
  14. global ISP router · Link [Hl | Ht | GET /index.html]A brand-new link header is added for the next link. It may be a completely different link technology — Ethernet here, WiFi next — and the header changes to match.
  15. global ISP router · Physical [Hl | Ht | GET /index.html]The frame goes out onto the next link as bits.
  16. www.example.edu · Physical [Hl | Hn | Ht | GET /index.html]The bits arrive and are reassembled into a frame.
  17. www.example.edu · Link [Hn | Ht | GET /index.html]The old link header is removed and discarded. It described the link the frame just crossed, and that link is behind us now.
  18. www.example.edu · Network [Ht | GET /index.html]The network layer removes Hn and passes the segment up.
  19. www.example.edu · Transport [GET /index.html]The transport layer removes Ht, checks it, and works out which application the message belongs to.
  20. www.example.edu · Application [GET /index.html]The message arrives at the application, byte for byte what was sent.

The single most important detail in this section

Transport-layer protocols are implemented in end systems, and nowhere else. Look at the routers in the animation above: they have a network layer, a link layer and a physical layer, and where the transport layer would be there is nothing.

A router acts only on the network-layer fields of a datagram. It does not examine — is not permitted to examine, and has no code to examine — the fields of the transport-layer segment inside. The transport header is written once, by the sending host, and read once, by the receiving host. Every machine in between carries it without looking.

This is why two consenting hosts can deploy a new transport protocol without asking anybody’s permission. It is also why section 3.8 ends the chapter with a protocol that does TCP’s job entirely in the application layer.

How the transport layer relates to the network layer

The transport layer sits just above the network layer. The distinction between them is subtle and worth being slow about:

  • a transport-layer protocol provides logical communication between processes;
  • a network-layer protocol provides logical communication between hosts.

Everyday picture

Two houses, one on each coast, each home to a dozen children. The children in one house are cousins of the children in the other, and they love to write. Each child writes to each cousin every week, each letter in its own envelope. So 144 letters cross the country each way, every week.

In each house one child handles the post: Ann in the West, Bill in the East. Ann collects the outgoing letters from her brothers and sisters and hands them to the mail carrier; when post arrives, she distributes it. Bill does the same at his end.

The postal service moves post from house to house, not from person to person. Ann and Bill are what turn house-to-house delivery into cousin-to-cousin delivery. And notice: from a cousin’s point of view, Ann and Bill are the mail service, even though they are only the end-system part of it.

Where the picture breaks: Ann and Bill can read the envelopes, decide to open one, or hold a letter back. A transport protocol has no such freedom — it runs the same code on every segment. The analogy also makes the postal service sound like one organisation. The Internet is not one organisation, and section 1.3.3 showed how many independent networks a packet crosses.

The two households, and what maps onto what
1 — Twelve cousins at each endstep 1 of 6
West Coast houseEast Coast housethe postal service12 children12 children144 letters each way, every week

Each house is home to a dozen children, and every child writes to every cousin once a week. That is 12 × 12 = 144 letters travelling in each direction every week.

Twelve children in each house, each writing to each of their twelve cousins every week. Step forward — the last two steps are the ones that matter.

Read all steps as text
  1. 1 — Twelve cousins at each endEach house is home to a dozen children, and every child writes to every cousin once a week. That is 12 × 12 = 144 letters travelling in each direction every week.
  2. 2 — One child in each house does the sortingAnn in the West and Bill in the East collect the outgoing post from their brothers and sisters, hand it to the mail carrier, and hand out whatever arrives. Nobody else in either house deals with the carrier.
  3. 3 — The carrier moves sacks between houses, not between peopleThe postal service takes a sack from one address and delivers it to another address. It never learns that Ann and Bill exist, and it certainly never learns which cousin a letter is for.
  4. 4 — The mapping, in five linesLetters in envelopes are application messages. Cousins are processes. Houses are hosts. Ann and Bill are the transport-layer protocol. The postal service, mail carriers and all, is the network-layer protocol.
  5. 5 — Ann and Bill go on holidaySusan and Harvey take over. Being younger, they collect less often and occasionally lose a letter — the family dog chews some. Same houses, same postal service, same cousins, and a noticeably worse service. One network can offer several transport protocols, each with its own promises. This is TCP and UDP.
  6. 6 — What Ann and Bill can and cannot promiseIf the postal service will not promise three-day delivery, Ann and Bill cannot promise it either — they never touch a letter while it travels. But they *can* promise that every letter eventually arrives, by keeping a copy and sending it again until the cousin confirms. Reliability can be added on top. A delay guarantee cannot.

Two things follow from the analogy, and both are load-bearing for the whole chapter.

One network, several transport protocols

When Ann and Bill go on holiday, Susan and Harvey take over. They are younger. They collect the post less often and occasionally lose a letter — some are chewed by the family dog. Same houses, same postal service, same cousins, and a distinctly worse service.

In exactly the same way, one network can make several transport protocols available, each offering a different service model to applications. The Internet offers two, and they are about as far apart as Ann and Susan.

What can and cannot be added on top

The services Ann and Bill can offer are limited by what the postal service offers. If the postal service will not promise that a letter arrives within three days, then Ann and Bill cannot promise it either. They never touch a letter while it is in transit, so there is no point at which they could make it move faster.

The same constraint binds every transport protocol: if the network layer cannot guarantee delay or throughput between hosts, the transport layer cannot guarantee delay or throughput between processes.

In plain words

You cannot promise something that depends on someone else’s behaviour, if that someone has made you no promise.

But you can promise things that depend only on your own behaviour. Ann can guarantee that every letter eventually arrives, by keeping a copy and sending it again until the cousin confirms receipt. That takes patience, not cooperation from the postal service.

So the rule is not “the transport layer can add nothing”. It is: the transport layer can add anything the two ends can accomplish by themselves. Reliable data transfer is one such thing, and section 3.4 builds it from nothing. Confidentiality is another — a transport protocol can encrypt, so that messages cannot be read in transit even though the network layer offers no confidentiality at all. Chapter 8 does that.

A delay bound is not such a thing. Neither is a throughput floor. Those need the network to behave differently, and it will not.

The transport layer in the Internet

The Internet makes two transport-layer protocols available. Chapter 2 named them; here is what they are.

UDP — the User Datagram Protocol — provides an unreliable, connectionless service. TCP — the Transmission Control Protocol — provides a reliable, connection-oriented service. When you write a network application you must pick one, and section 2.7 showed exactly where: the choice is made in the line that creates the socket.

A word about the word “segment”

This site calls the transport-layer packet a segment, for both TCP and UDP.

The book does the same, and explains why. The RFC (Request For Comments) s call a TCP packet a segment, but usually call a UDP packet a datagram — and the same literature also uses datagram for the network-layer packet. That is one word doing two jobs at two layers, which is precisely the sort of thing that makes a subject harder than it needs to be.

So: segment is the transport-layer packet, always. Datagram is the network-layer packet, always. If you meet “UDP datagram” in an RFC, it means what this site calls a UDP segment.

What the layer below actually gives you

The Internet’s network-layer protocol is IP (Internet Protocol) , and it provides logical communication between hosts. Chapters 4 and 5 cover it properly. For this chapter you need two facts.

The first is that every host has at least one network-layer address, an IP address. The second is the important one: IP’s service model is a best-effort delivery service . IP makes its best effort to deliver segments between hosts, and it makes no guarantees. It does not guarantee that a segment arrives. It does not guarantee that segments arrive in the order they were sent. It does not guarantee that the data inside is undamaged. For these reasons IP is called an unreliable service.

So what do UDP and TCP actually add?

The most fundamental responsibility of both is the same: extend IP’s delivery service between two end systems into a delivery service between two processes running on those end systems. That is transport-layer multiplexing and demultiplexing, and it is the subject of section 3.2.

Both also provide integrity checking, by including error-detection fields in their segment headers.

Process-to-process delivery and error checking are the only two services UDP provides. That is the complete list. Like IP, UDP is unreliable: it does not guarantee that data sent by one process arrives intact at the destination process, or arrives at all.

TCP adds several more, and the rest of this chapter is largely about how.

What you get, layer by layer
IPthe network layerUDPhost → process, and no moreTCPhost → process, plus guarantees
Communicates between
Guarantees delivery
Guarantees order
Checks the data is undamaged
Protects a slow receiver
Protects the network
Needs a handshake first

Cells marked ⓘ have a reason behind them — click to read it.

Read the IP column first. Everything in the other two columns is something the two end systems added for themselves, because IP would not do it. Click a ⓘ for the reason.

The one service that is not for you

TCP’s list has an oddity in it worth pointing out now, because it will look strange later otherwise.

Reliable data transfer is plainly a service for the two communicating processes. TCP ensures data is delivered from sending process to receiving process, correctly and in order. It does that with flow control, sequence numbers, acknowledgements and timers — all of which this chapter builds. TCP converts IP’s unreliable service between end systems into a reliable transport service between processes. That is for you.

Congestion control is not. It is less a service for the invoking application than a service for the Internet as a whole. The book calls it a service for the general good. Loosely speaking, TCP congestion control stops any single connection from swamping the links and routers between the two hosts with more traffic than they can carry. It also tries to give each connection crossing a congested link an equal share of that link.

From the point of view of one impatient sender, this is a cost, not a benefit. And UDP traffic is not regulated at all: an application using UDP can send at any rate it pleases, for as long as it pleases. Hold on to that asymmetry — section 3.7 returns to it, and it turns out to matter a great deal.

In plain words

TCP is polite. UDP is not. Politeness costs the polite party something and benefits everybody else — which is a familiar problem, and it has the familiar consequence that not everybody chooses to be polite.

Where the chapter goes from here

A protocol that provides both reliable data transfer and congestion control is necessarily complicated, so the chapter alternates between principle and practice rather than doing either all at once:

  1. Section 3.2 — multiplexing and demultiplexing, the service no transport protocol can skip.
  2. Section 3.3 — UDP, which does that and almost nothing else.
  3. Section 3.4 — reliable data transfer in general, built from nothing over five successive protocols.
  4. Section 3.5 — how TCP does it.
  5. Section 3.6 — congestion in general: why it happens and what it costs.
  6. Section 3.7 — how TCP handles it.
  7. Section 3.8 — what people are building now that neither protocol quite fits.

Check yourself

Check yourself

0 of 5 answered
  1. 1.A datagram carrying a TCP segment passes through eleven routers on its way from Bangkok to Frankfurt. How many of those routers read the TCP header?

    Look at the layer boxes drawn on the routers in the figure.

  2. 2.In the household analogy, what plays the part of the transport-layer protocol?

  3. 3.The postal service refuses to promise that any letter arrives within three days. Which of these can Ann and Bill still promise the cousins?

    Separate the promises you can keep by working harder from the promises that need the carrier's cooperation.

  4. 4.Which two services does UDP provide, and only those two?

  5. 5.predictYou set the comparison grid to look at congestion control. It is listed as a service TCP provides. Who is it a service *for*?

What to remember

  • The transport layer turns host-to-host delivery into process-to-process delivery. That is its one irreducible job.
  • Transport protocols run only in end systems. Routers implement the network, link and physical layers, and never look inside a segment.
  • A transport protocol cannot offer a guarantee that needs the network layer’s cooperation: no delay bound, no throughput floor. It can offer anything the two ends achieve alone — reliable delivery over an unreliable network, and confidentiality over a network that offers none.