The Transport Layer

IP delivers a packet to a machine; the transport layer delivers data to a process on that machine and, if the application wants it, makes the unreliable network behave like a reliable pipe.

Two protocols dominate: UDP, which adds almost nothing to IP, and TCP, which adds connections, reliability, flow control and congestion control.

Understanding TCP's window arithmetic is one of the most-examined skills in the subject, so the numbers here are recomputed by check_networking.py and by the programs at the end of the unit.

5.1 Functions of the transport layer

The transport layer provides process-to-process communication using port numbers (16 bits, 0–65,535).

Well-known ports 0–1023 identify standard services (80 HTTP, 443 HTTPS, 53 DNS, 25 SMTP, 22 SSH, 21 FTP, 67/68 DHCP); registered ports go to 49151; the rest are ephemeral ports a client picks for itself.

A socket address is an IP address plus a port, and a TCP connection is identified by the four-tuple (source IP, source port, destination IP, destination port); that is why a web server on port 80 can serve thousands of clients.

Multiplexing at the sender gathers data from several processes and marks each segment with ports; demultiplexing at the receiver delivers each segment to the right socket. UDP demultiplexes by (destination IP, destination port) only; TCP by the whole four-tuple.

The layer may also provide segmentation, end-to-end error control, flow control (match the receiver's speed) and congestion control (match the network's capacity).

The difference between the flow and the congestion is the key distinction: flow control protects the receiver, congestion control protects the network.

5.2 UDP

The User Datagram Protocol is connectionless, unreliable and message-oriented. Its header is 8 bytes: source port, destination port, length and checksum (2 bytes each).

There is no handshake, no retransmission, no ordering and no congestion control, so it has low overhead and low delay.

Use it for DNS queries, DHCP, streaming and calls, online games, SNMP and for new transports built on top of it (QUIC runs over UDP).

The checksum is the Internet checksum (Unit 3) computed over the UDP header, the data and a pseudo-header (source IP, destination IP, protocol 17, UDP length), so that a datagram delivered to the wrong host is detected.

In IPv4 the UDP checksum is optional (0 means none); in IPv6 it is mandatory.

RPC (remote procedure call) lets a program call a procedure on another machine as if it were local: a client stub packs the parameters (marshalling) and sends them; a server stub unpacks, calls the real procedure and returns the result.

It is usually built on UDP or TCP and is the base of many distributed systems (Unit on Distributed Systems later in the course).

5.3 Principles of reliable data transfer

Reliable transfer over an unreliable channel is built step by step:

Version	Channel assumption	Mechanism added
rdt 1.0	perfectly reliable	nothing
rdt 2.0	bit errors, no loss	checksum, ACK and NAK, retransmit
rdt 2.1 / 2.2	ACK or NAK may be corrupt	sequence numbers 0/1; duplicate ACK replaces NAK
rdt 3.0	errors and loss	countdown timer and retransmission (stop-and-wait, alternating bit)
Pipelined	the above, but fast	GBN or SR with sliding windows (Unit 3)

Stop-and-wait is correct but slow: on a 1 Gbps path with 30 ms round trip and 1000-byte packets, utilisation is \dfrac{8000 / 10⁹}{30 ms + 8 µs} ≈ 0.027 %. Pipelining raises it almost linearly with the window.

TCP's mechanism is a hybrid: cumulative acknowledgements like GBN, but with receiver buffering of out-of-order segments like SR.

5.4 TCP services and the segment

TCP is connection-oriented, reliable, full-duplex, byte-stream based and flow- and congestion-controlled.

The application writes bytes; TCP cuts them into segments no larger than the MSS (usually 1460 bytes on Ethernet: MTU 1500 − 20 − 20) and numbers each byte with a 32-bit sequence number.

Field	Bits	Meaning
Source and destination port	16 + 16
Sequence number	32	number of the first data byte in the segment
Acknowledgement number	32	next byte expected (cumulative)
Header length	4	in 32-bit words (5 to 15)
Flags	9	URG, ACK, PSH, RST, SYN, FIN (and ECE, CWR, NS)
Window	16	receiver's advertised window in bytes
Checksum	16	header + data + pseudo-header
Urgent pointer	16
Options	0–40 bytes	MSS, window scale, SACK, timestamps

Connection establishment: the three-way handshake

1. Client → server: SYN, seq = x (the client's initial sequence number, ISN).
2. Server → client: SYN + ACK, seq = y, ack = x + 1.
3. Client → server: ACK, seq = x + 1, ack = y + 1.

With x = 1000 and y = 5000: SYN (seq 1000), SYN-ACK (seq 5000, ack 1001), ACK (seq 1001, ack 5001). If the client then sends 300 bytes, the segment has seq 1001 and length 300, so the next expected sequence number is 1301.

The SYN consumes one sequence number. Random ISNs stop old duplicate segments of a previous connection being accepted and make blind spoofing harder.

A SYN flood attack sends many SYNs and never completes the handshake, filling the server's half-open connection queue; defences are SYN cookies and rate limiting.

Connection release

Each direction closes independently: FIN from one side, ACK from the other; four segments in the normal case (FIN, ACK, FIN, ACK).

The side that closes first enters TIME_WAIT for two maximum-segment lifetimes (typically 60 seconds) so that a lost final ACK can be retransmitted and old segments die out. RST aborts a connection immediately.

TCP states in brief

Client: CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED. Server: CLOSED → LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED. The command ss -tan lists the states of the sockets on a Linux host.

5.5 Flow control

The receiver advertises its free buffer space in the window field (rwnd). The sender keeps at most rwnd unacknowledged bytes in flight.

If the window drops to zero, the sender stops and probes with tiny segments so that a lost window update cannot deadlock the connection.

Silly window syndrome (tiny windows repeatedly advertised and used) is avoided by the receiver not advertising until it can take at least one MSS and the sender not sending tiny segments (Nagle's algorithm: while unacknowledged data exists, buffer small writes).

The 16-bit window field limits the window to 65,535 bytes without scaling. Throughput is at most window / RTT, so with a 100 ms round trip the cap is 65,535 × 8 / 0.1 = 5.24 Mbps whatever the link speed.

A 1 Gbps path with a 50 ms RTT needs a window of 10⁹ × 0.05 / 8 = 6,250,000 bytes, which is why the window scale option (a shift of up to 14, window up to about 1 GB) exists.

5.6 Error control and timers

TCP detects damage by checksum and loss by missing acknowledgements. Cumulative ACK: ack = n means "everything before byte n arrived".

If a segment is lost, later segments produce duplicate ACKs for the same n. After three duplicate ACKs, the sender performs fast retransmit of the missing segment without waiting for the timer.

SACK adds ranges of received bytes so that several losses can be repaired in one round trip.

Retransmission timeout

If the timer is too short, TCP sends needless duplicates; if too long, it reacts slowly. TCP measures the round-trip time and keeps a smoothed value and a deviation (Jacobson's algorithm, with α = 1/8 and β = 1/4):

• RTTVAR = (1 − β) RTTVAR + β |SRTT − R|
• SRTT = (1 − α) SRTT + α R
• RTO = SRTT + 4 RTTVAR

5.7 Congestion control

Too many senders cause queues to overflow and packets to be dropped; retransmissions then add more load, a feedback that can lead to congestion collapse.

TCP responds with an end-to-end scheme: the sender keeps a congestion window (cwnd) and sends min(cwnd, rwnd) bytes. It treats a loss as a signal of congestion.

• Slow start: begin with cwnd = 1 MSS and double cwnd every round trip (add one MSS per ACK) until it reaches the slow-start threshold ssthresh. It is "slow" only compared with sending a full window at once.
• Congestion avoidance: above ssthresh, increase cwnd by about one MSS per round trip (additive increase).
• On a timeout (severe): ssthresh = cwnd / 2, cwnd = 1 MSS, return to slow start (Tahoe; also Reno on a timeout).
• On three duplicate ACKs (milder): Reno sets ssthresh = cwnd / 2 and cwnd = ssthresh (fast recovery), continuing in congestion avoidance.

The combination is AIMD: additive increase, multiplicative decrease. Modern stacks use CUBIC (Linux) or BBR, but AIMD is the textbook model.

Throughput and fairness

For a long-lived TCP flow, the average throughput is about MSS / RTT × 1.22 / √p (Mathis formula) where p is the loss probability: with MSS = 1460 bytes, RTT = 100 ms and p = 1 % that is 1460 × 8 / 0.1 × 1.22 / 0.1 ≈ 1.42 Mbps.

AIMD also converges to a fair share: when two flows share a bottleneck, additive increase raises both rates by the same amount (keeping their gap), and each multiplicative decrease halves the gap.

If the flows start with rates 10 and 60 and the link capacity is 100, the gap of 50 becomes 25 after the first loss and 12.5 after the second; repeated losses bring them to equality.

UDP flows have no such control and can crowd out TCP, which is why streaming protocols add their own rate control.

5.8 Elements of transport protocols

• Addressing: a transport address is (IP, port); well-known ports let a client find a server. A portmapper or name service can assign ports dynamically.
• Establishing connections: the hard problem is delayed duplicates. The three-way handshake with fresh sequence numbers solves it.
• Releasing: a symmetric release is impossible to guarantee (the two-army problem), so TCP uses timers and TIME_WAIT.
• Flow control and buffering: buffers at the sender (for retransmission) and receiver (to reorder); a variable window tied to buffer space.
• Multiplexing: many transport connections over one network connection (and the reverse, inverse multiplexing for bandwidth).
• Crash recovery: after a host crash the application must decide whether the last request was done; no transport protocol can resolve this ambiguity by itself (the reason for idempotent requests).

5.9 Sockets in practice

A program reaches TCP and UDP through the socket API: a server calls socket, bind, listen and accept; a client calls socket and connect; both then send and recv.

The following program starts a small TCP server in a thread and a client on the loopback interface, prints the four-tuple the way TCP sees it, then does one UDP exchange.

import socket, threading
srv = socket.socket(); srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
srv.bind(("127.0.0.1", 50007)); srv.listen(1)
def serve():
    conn, addr = srv.accept()
    data = conn.recv(1024); conn.sendall(b"ECHO:" + data); conn.close()
t = threading.Thread(target=serve); t.start()
c = socket.create_connection(("127.0.0.1", 50007))
print("server socket", c.getpeername(), "client uses an ephemeral port:", c.getsockname()[1] >= 32768)
c.sendall(b"hello"); print(c.recv(1024)); c.close(); t.join(); srv.close()
u = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); u.bind(("127.0.0.1", 50008))
s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); s2.sendto(b"datagram", ("127.0.0.1", 50008))
print(u.recvfrom(100)[0])

server socket ('127.0.0.1', 50007) client uses an ephemeral port: True
b'ECHO:hello'
b'datagram'

A second program reproduces the congestion-window and RTO tables of this unit.

def trace(rounds, ssth, loss_at, tahoe):
    cw, rows = 1, []
    for t in range(1, rounds + 1):
        rows.append(cw)
        if t == loss_at: ssth = max(cw // 2, 2); cw = 1 if tahoe else ssth
        elif cw < ssth: cw = min(cw * 2, ssth)
        else: cw += 1
    return rows
print("Tahoe", trace(14, 16, 8, True)); print("Reno ", trace(14, 16, 8, False))
srtt, rttvar = 100, 50
for r in (120, 90, 140, 100):
    rttvar = 0.75 * rttvar + 0.25 * abs(srtt - r); srtt = 0.875 * srtt + 0.125 * r
    print(r, round(rttvar, 2), round(srtt, 2), round(srtt + 4 * rttvar, 2))
print("window/RTT cap Mbps:", round(65535 * 8 / 0.1 / 1e6, 2), " window for 1 Gbps, 50 ms:", int(1e9 * 0.05 / 8))

Tahoe [1, 2, 4, 8, 16, 17, 18, 19, 1, 2, 4, 8, 9, 10]
Reno  [1, 2, 4, 8, 16, 17, 18, 19, 9, 10, 11, 12, 13, 14]
120 42.5 102.5 272.5
90 35.0 100.94 240.94
140 36.02 105.82 249.88
100 28.47 105.09 218.96
window/RTT cap Mbps: 5.24  window for 1 Gbps, 50 ms: 6250000

5.10 Seeing the ideas: ports, segments, windows and congestion

The transport layer is mostly about numbers that every student must be able to compute: sequence numbers, windows, timers and rates.

Plate 5.1 shows three of the people behind it: Bob Kahn and Vint Cerf, who designed TCP, and Van Jacobson, whose 1988 congestion-control algorithms saved the Internet from collapse.

Plate 5.2 gives three everyday pictures of the ideas: a container port (multiplexing and ports), a ticket hall (queues and waiting for service) and a mountain road jammed with trucks (congestion).

The figures that follow compute the unit's examples: ports and sockets, the UDP and TCP headers, the handshake and release with real sequence numbers, window utilisation, the window cap, the retransmission timer, Tahoe and Reno, AIMD fairness and the throughput formula.

(a) Bob Kahn: TCP/IP

(b) Vint Cerf: TCP/IP

(c) Van Jacobson: congestion control

(a) Container port: ports, multiplexing

(b) Ticket hall: queues, delay

(c) Mountain road jam: congestion

5.10.1 Eight uses of transport protocols in Nepal

1. Secure web browsing and payments. When you open ConnectIPS or a bank site, your browser makes a TCP connection to port 443 with the three-way handshake (Fig. 5.3) and then runs TLS inside it. TCP numbers every byte and retransmits lost segments, so a payment instruction cannot arrive damaged or out of order. The same reliability is why a failed payment shows an error instead of a half-finished transfer.
2. DNS lookups over UDP. Every web address is first turned into an IP address by a short UDP query to port 53, with an 8-byte header and no connection set-up (Fig. 5.2). One packet out and one packet back is far faster than a handshake. If the answer is lost the resolver simply asks again, which is cheaper than TCP for such small messages.
3. Video calls and streaming. Calls on Viber, WhatsApp and Zoom and live streams run over UDP, because a late packet is useless and retransmitting it would only add delay. The application hides small losses with its own correction. This is why a call may break up for a moment but never freezes while waiting for old data.
4. Large downloads over long paths. A software update or a video from an overseas server travels over a path with a long round-trip time. Without the window-scale option the speed would be capped at a few megabits per second (Fig. 5.5), so modern operating systems enable scaling automatically. Choosing a nearby mirror lowers the round trip and raises the speed.
5. Sharing a mobile or Wi-Fi link. When many students in a hostel use the same link, packets are dropped at the router queue and every TCP flow halves its window (Fig. 5.7). AIMD makes the flows share the capacity about equally without any central control (Fig. 5.8). A slow link is therefore shared rather than monopolised by one download.
6. Loss on weak signals. On a weak mobile signal a small loss rate lowers throughput sharply (Fig. 5.9), which is why the speed test falls far below the advertised rate. Moving to a better signal helps more than buying a faster plan. The Mathis formula shows that the cure is lower loss or a shorter round trip.
7. Firewalls and SYN floods. A server's firewall allows only the ports it needs, such as 80 and 443, and drops the rest (Fig. 5.1). A SYN flood sends many SYN segments and never finishes the handshake, filling the table of half-open connections. Limits on half-open connections and SYN cookies protect public portals during result days.
8. Socket programming in student projects. A client-server chat or a small web service written in Python or Java uses sockets: bind, listen and accept on the server, connect on the client. The program sees a reliable byte stream and never handles sequence numbers itself. Writing one in the lab makes the ports, the four-tuple and the handshake concrete.

Formula and fact sheet

• UDP header 8 bytes; TCP header 20–60 bytes; MSS = MTU − 40 = 1460 on Ethernet.
• Handshake: SYN (x), SYN-ACK (y, x + 1), ACK (x + 1, y + 1). SYN and FIN each use one sequence number.
• Throughput ≤ window / RTT. Window needed = bandwidth × RTT.
• RTO = SRTT + 4 RTTVAR; α = 1/8, β = 1/4. Karn: skip retransmitted samples.
• cwnd: slow start doubling, then +1 MSS per RTT; on loss ssthresh = cwnd / 2; Tahoe cwnd = 1, Reno cwnd = ssthresh.
• Mathis: rate ≈ 1.22 MSS / (RTT √p).

Chapter summary

• The transport layer gives process-to-process delivery with ports. UDP is a thin, fast, unreliable service; TCP is a reliable byte stream.
• TCP sets up with a three-way handshake, numbers bytes, acknowledges cumulatively, retransmits on timeout or three duplicate ACKs and tears down with FINs.
• Flow control uses the receiver's window; congestion control uses cwnd with slow start, additive increase and multiplicative decrease.
• Throughput is bounded by window / RTT, which is why high-speed long-delay paths need window scaling.

Practice

1. Differentiate TCP and UDP and give two applications of each.
2. Describe the three-way handshake with ISNs 1000 and 5000. What is the next sequence number after 300 bytes of data?
3. Why can a web server on port 80 serve many clients at once?
4. What is the maximum throughput of a TCP connection with a 65,535-byte window and 100 ms RTT? What window does 1 Gbps with 50 ms need?
5. Explain fast retransmit.
6. Compute the RTO after samples 120, 90, 140 and 100 ms if the first sample was 100 ms.
7. Draw the Tahoe and Reno cwnd for 14 rounds with ssthresh 16 and a loss in round 8.
8. State Karn's rule and why it is needed.
9. Distinguish flow control from congestion control.
10. Why is the UDP checksum computed over a pseudo-header?
11. What is a SYN flood and one defence?

Answers and worked solutions

1. TCP: connection-oriented, reliable, ordered, flow and congestion controlled (web, e-mail, file transfer). UDP: connectionless, best effort, 8-byte header (DNS, streaming, VoIP).

2. SYN (seq 1000); SYN-ACK (seq 5000, ack 1001); ACK (seq 1001, ack 5001). After 300 data bytes starting at 1001, the next sequence number is 1301.

3. TCP demultiplexes by the four-tuple, so each client's (IP, port) pair gives a different connection to the same server port.

4. 65,535 × 8 / 0.1 = 5.24 Mbps. For 1 Gbps and 50 ms: 6,250,000 bytes (window scaling needed).

5. After three duplicate ACKs for the same sequence number the sender assumes that segment was lost and resends it immediately without waiting for the timeout.

6. Final RTO = 218.96 ms (table in Section 5.6).

7. Tahoe 1 2 4 8 16 17 18 19 1 2 4 8 9 10; Reno 1 2 4 8 16 17 18 19 9 10 11 12 13 14.

8. Do not take RTT samples from retransmitted segments, because it is unclear which transmission the ACK acknowledges; use exponential backoff for the timer instead.

9. Flow control keeps a fast sender from overflowing a slow receiver (rwnd); congestion control keeps senders from overloading the network (cwnd).

10. It lets the receiver verify that the datagram was meant for its IP address and protocol, catching misdelivery by IP.

11. The attacker sends SYNs without finishing the handshake, filling the half-open queue. SYN cookies let the server avoid storing state until the final ACK arrives.

Model answers for Unit 5

Q1. Explain TCP connection establishment and release with the sequence numbers. (10 marks)

Introduction. TCP is a connection-oriented, reliable, full-duplex byte-stream protocol. Before data flows the two ends must agree on their initial sequence numbers, and when the exchange finishes each direction is closed separately.

Fig. 5.3 shows the whole life of a connection.

Three-way handshake. The client first sends a SYN segment, the server answers with SYN + ACK, and the client confirms with an ACK. With the client's initial sequence number x = 1000 and the server's y = 5000:

Step	Direction	Flags	Seq	Ack
1	client to server	SYN	1000	none
2	server to client	SYN + ACK	5000	1001
3	client to server	ACK	1001	5001

The SYN consumes one sequence number, which is why the acknowledgements are x + 1 and y + 1. If the client now sends 300 bytes they carry sequence numbers 1001 to 1300, so the server acknowledges 1301, the next byte expected.

Why three steps and random numbers. The handshake proves that both ends can send and receive, and a random initial sequence number prevents an old duplicate segment from a previous connection being accepted as new data.

A SYN flood attack sends many SYNs and never completes step 3; servers defend with SYN cookies and limits on half-open connections.

Release. Each direction closes by itself, so four segments are normal: the client sends FIN (seq 1301), the server acknowledges (ack 1302), then the server sends its own FIN (seq 5001) and the client acknowledges (ack 5002).

The side that closes first enters TIME_WAIT for twice the maximum segment lifetime (about 60 seconds), so that a lost last ACK can be re-sent and old segments disappear. A RST segment aborts a connection at once.

States. The client goes CLOSED, SYN_SENT, ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, TIME_WAIT, CLOSED. The server goes CLOSED, LISTEN, SYN_RCVD, ESTABLISHED, CLOSE_WAIT, LAST_ACK, CLOSED.

Example for the exam. If the client sends 300 bytes at sequence 1001, the segment ends at byte 1300 and the ACK carries 1301; if the first segment is lost, the server keeps acknowledging 1001, and after three such duplicate ACKs the client retransmits at once.

TCP states can be listed with the command ss -tan on Linux.

Conclusion. The handshake and the release give TCP a clean beginning and end, at the cost of one round trip before any data and a short waiting period at the close.

Q2. Explain TCP congestion control. Compare Tahoe and Reno using a cwnd trace. (10 marks)

Introduction. Flow control protects the receiver, but congestion control protects the network. When too many senders fill a router's queues, packets are dropped, and retransmissions can make matters worse, which is congestion collapse.

TCP therefore keeps a congestion window cwnd and sends min(cwnd, rwnd) bytes.

The algorithms.

1. Slow start. cwnd begins at 1 MSS and doubles every round trip (one MSS added per ACK) until it reaches the threshold ssthresh.
2. Congestion avoidance. Above ssthresh, cwnd grows by about one MSS per round trip, which is additive increase.
3. Timeout. A timeout means severe congestion: ssthresh = cwnd / 2 and cwnd = 1, then slow start again (Tahoe, and Reno on a timeout).
4. Three duplicate ACKs. They mean one segment was lost but later ones arrived, so the network is only mildly congested. Reno performs fast retransmit, sets ssthresh = cwnd / 2 and cwnd = ssthresh (fast recovery) and continues in congestion avoidance.
5. AIMD. The pattern, additive increase and multiplicative decrease, makes flows converge to a fair share (Fig. 5.8).

Trace (Fig. 5.7). ssthresh = 16 and a loss at round 8, when cwnd = 19:

Round	1	2	3	4	5	6	7	8	9	10	11	12	13	14
Tahoe	1	2	4	8	16	17	18	19	1	2	4	8	9	10
Reno	1	2	4	8	16	17	18	19	9	10	11	12	13	14

The new ssthresh is 19 / 2 = 9. Tahoe falls to 1 and needs four more rounds to climb back, while Reno continues from 9. Over 14 rounds Reno sends 154 MSS against 119 for Tahoe.

Throughput and fairness. Averaged over time, a flow with loss probability p, round trip RTT and segment size MSS gets about MSS / RTT x 1.22 / \sqrt{p}: with 1460 bytes, 100 ms and 1 percent loss this is 1.42 Mbps (Fig. 5.9).

Modern stacks replace the exact rules by CUBIC (Linux, Windows) or BBR, which estimates the bottleneck rate, but all of them keep the idea of probing gently and backing off on loss.

Conclusion. Slow start probes for capacity quickly, congestion avoidance probes gently, and the halving on loss backs off sharply. Reno's fast recovery wastes less capacity than Tahoe because duplicate ACKs show that the pipe is still flowing.

Q3. Compare UDP and TCP. When is each suitable? (10 marks)

Introduction. Both protocols deliver data to a process using port numbers, but they make opposite choices about reliability and overhead (Fig. 5.2).

UDP. The User Datagram Protocol is connectionless and message-oriented. Its header is 8 bytes: source port, destination port, length and checksum.

It sets up no connection, retransmits nothing, does not order the datagrams and does not slow down when the network is congested.

Its checksum covers the header, the data and a pseudo-header with the IP addresses, so a datagram delivered to the wrong host is detected.

TCP. The Transmission Control Protocol is connection-oriented and byte-stream based. Its header is at least 20 bytes.

It numbers every byte, acknowledges data, retransmits losses, reorders segments, controls the flow with the receive window and controls congestion with cwnd.

Feature	UDP	TCP
Connection	none	handshake before data
Header	8 bytes	20 to 60 bytes
Reliability	none	acknowledgements, retransmission
Ordering	none	sequence numbers
Flow and congestion control	none	window and cwnd
Delay	low	higher (handshake, waiting)
Unit of data	message with boundaries	stream of bytes
Typical use	DNS, DHCP, calls, games, QUIC	web, e-mail, file transfer, banking

Choosing. Use TCP when every byte must arrive correctly and in order, as in web pages, e-mail, file transfers and payments.

Use UDP when speed matters more than perfection or when the message is tiny: a DNS query, a live video frame, or a game position that is out of date as soon as a newer one arrives.

UDP is also the base for new protocols such as QUIC, which build their own reliability and congestion control above it.

Overhead example. A DNS query of 30 bytes in UDP costs one datagram out and one back, 2 packets in all.

The same exchange over TCP needs a three-segment handshake, the request, the reply, and four release segments, about 10 packets, and at least one extra round trip before the first byte is sent.

For a tiny, repeatable request that is a heavy price, which is why DNS, DHCP and SNMP choose UDP.

Conclusion. TCP gives a reliable pipe at the price of delay and overhead, and UDP gives the application raw speed and control. Neither is better; the application decides.

Q4. Explain TCP flow control and the window-scale option. (5 marks)

Flow control stops a fast sender from overrunning a slow receiver. The receiver puts its free buffer space in the window field of every acknowledgement (rwnd), and the sender keeps no more than rwnd unacknowledged bytes in flight.

1. Zero window. If the window becomes 0 the sender stops and sends small probe segments, so that a lost window update cannot cause a deadlock.
2. Silly window syndrome. Tiny windows repeatedly advertised and filled with tiny segments waste capacity; the receiver waits until it can accept one MSS, and the sender uses Nagle's rule to gather small writes.
3. The 64 KB limit. The window field has 16 bits, so at most 65 535 bytes can be in flight. Throughput is then at most window x 8 / RTT: 5.24 Mbps at a round trip of 100 ms (Fig. 5.5), however fast the link.
4. Window scale. A link of 1 Gbps with RTT 50 ms needs a window of 10^{9} x 0.05 / 8 = 6 250 000 bytes. The window-scale option, agreed in the SYN, shifts the field left by up to 14 bits, allowing windows near 1 GB.
5. Difference. Flow control protects the receiver, while congestion control protects the network, and the sender obeys the smaller of rwnd and cwnd.

Q5. How does TCP set its retransmission timeout? Compute the RTO for the samples 100, 120, 90, 140 and 100 ms. (5 marks)

If the timeout is too short TCP sends needless duplicates, and if too long it reacts slowly to loss, so TCP measures the round trip and adapts. Jacobson's algorithm keeps a smoothed RTT and a deviation:

• RTTVAR = 0.75 x RTTVAR + 0.25 x |SRTT - R|
• SRTT = 0.875 x SRTT + 0.125 x R
• RTO = SRTT + 4 x RTTVAR

The first sample, 100 ms, gives SRTT = 100, RTTVAR = 50 and RTO = 300 ms. The later samples give (Fig. 5.6):

Sample R	RTTVAR	SRTT	RTO
120	42.5	102.5	272.5
90	35.0	100.94	240.94
140	36.02	105.82	249.88
100	28.47	105.09	218.96

The timer therefore settles near twice the typical round trip, safely above the samples but not far above them.

Karn's rule: never take a sample from a retransmitted segment, because its acknowledgement could belong to either copy, and double the RTO after each timeout (exponential backoff).

Fast retransmit after three duplicate ACKs avoids waiting for the timer at all.

Q6. Explain the principles of reliable data transfer using the rdt versions. (5 marks)

Reliable transfer over an unreliable channel is built one problem at a time.

1. rdt 1.0. The channel is perfect, so the sender simply sends.
2. rdt 2.0. Bits may be damaged, so a checksum is added, the receiver sends ACK or NAK, and the sender retransmits on a NAK.
3. rdt 2.1 and 2.2. The ACK or NAK itself may be damaged, so frames carry a sequence number (0 or 1) to detect duplicates; 2.2 replaces the NAK by a duplicate ACK.
4. rdt 3.0. Packets may also be lost, so a countdown timer is added: if no ACK arrives in time the sender retransmits. This is stop-and-wait or the alternating-bit protocol.
5. Pipelining. Stop-and-wait is correct but slow (0.027 percent utilisation on a 1 Gbps path with a 30 ms round trip, Fig. 5.4), so Go-Back-N or Selective Repeat allows many packets in flight. TCP uses a hybrid: cumulative acknowledgements like Go-Back-N and buffering of out-of-order segments like Selective Repeat.

Q7. Explain why AIMD makes competing TCP flows converge to a fair share. (5 marks)

Two TCP flows share a bottleneck link of capacity C. Plot flow 1's rate on the x axis and flow 2's on the y axis (Fig. 5.8): the line x + y = C is full use of the link (efficiency) and the line x = y is equal sharing (fairness).

1. Additive increase. When there is no loss both flows add the same amount per round trip, so the point moves along a 45 degree line: the difference between the rates stays the same while the total rises.
2. Multiplicative decrease. When the total exceeds C, both flows halve their windows. The point moves toward the origin along the line to the origin, and the difference between the rates is halved too.
3. Convergence. Each cycle of increase and decrease leaves the efficiency near C but halves the unfairness. From a gap of 50 the gap becomes 25, 12.5, 6.3, 3.1 and 1.6 after five decreases.
4. Why not additive decrease. If both subtracted the same amount, the gap would never shrink, and the flows would not converge to fairness.
5. Limits. The fairness holds for flows with similar round-trip times; a flow with a shorter round trip gets a larger share, and applications opening many connections take more than their share.

Q8. What are ports and sockets? How do multiplexing and demultiplexing work? (5 marks)

The transport layer delivers data to a process, not just to a machine, using 16-bit port numbers (0 to 65 535).

1. Port ranges. Well-known ports 0 to 1023 name standard services (80 HTTP, 443 HTTPS, 53 DNS, 25 SMTP, 22 SSH, 67 and 68 DHCP). Registered ports go up to 49 151, and the rest are ephemeral ports that a client picks for itself.
2. Socket. A socket address is an IP address plus a port, such as 202.79.1.20:443. A program uses the socket API: a server calls socket, bind, listen and accept, a client calls socket and connect, and both send and receive.
3. Multiplexing. At the sender, data from several processes is put into segments marked with source and destination ports and handed to IP (Fig. 5.1).
4. Demultiplexing. At the receiver, the port numbers deliver each segment to the right socket. UDP uses only the destination IP and port; TCP uses the whole four-tuple (source IP, source port, destination IP, destination port), so two connections to the same server port are different.
5. Example. A browser with two tabs uses ports 51000 and 51001 to reach the same server port 443, and the server tells the two connections apart by the client port.