1. Chapter 6
The Transport Layer

2. Services Provided to the Upper Layers
The network, transport, and application layers.

3. Transport Service Primitives
The primitives for a simple transport service:
Example: Socket primitives for TCP:

4. Transport Service Primitives
A state diagram for a simple connection management scheme. Transitions labeled in italics are caused by packet arrivals. The solid lines show the client's state sequence. The dashed lines show the server's state sequence.

5. Transport Protocol (a) Environment of the data link layer.
(b) Environment of the transport layer.

6. TSAPs (port id), NSAPs (ip address) and transport connections.
Addressing
TSAPs (port id), NSAPs (ip address) and transport connections.

7. Connection Establishment
If user knows server port, he connects directly
If not:
A proxy server should be contacted first (see figure)
A name server is asked first for the port id of the server
User connects to process server (proxy) with known port
Process server spawns time-of-day server that inherits port id and handles user requests

8. Connection Establishment
Three protocol scenarios for establishing a connection using a three-way handshake. CR denotes CONNECTION REQUEST. (a) Normal operation, (b) Old CONNECTION REQUEST appearing out of nowhere. (c) Duplicate CONNECTION REQUEST and duplicate ACK.

9. Abrupt disconnection with loss of data.
Connection Release
Abrupt disconnection with loss of data.

10. Connection Release 6-14, a, b
Four protocol scenarios for releasing a connection. (a) Normal case of a three-way handshake. (b) final ACK lost.

11. Connection Release 6-14, c,d
(c) Response lost. (d) Response lost and subsequent DRs lost.

12. (a) Upward multiplexing. (b) Downward multiplexing.
Upward multiplexing: Different applications send at the same time (typical)
Downward multiplexing: One application using different connections (e.g. for speedup, e.g. in ISDN)
Demultiplexing: Direct traffic to the correct receiver (if many coexist)
Both constitute the most basic service of the transport layer
(a) Upward multiplexing. (b) Downward multiplexing.

13. Crash Recovery Client Server
Strategy A  P
Strategy P  A
Reissue strategy
APC
AC(P)
C(AP)
PAC
PC(A)
C(PA)
Always 2 1
Never
Only when ACKed
Only when not ACKed
Different combinations of client and server strategies in the presence of server crashes.
P: Processing, C: Crash, A: ACK
Server strategies: MP: Send ACK before processing
PA: Send ACK after processing
Thus: The number of executions of an operation depends on when the server crash has occurred.

14. The Internet Transport Protocol: UDP
UDP (User Datagram Protocol):
Almost IP
New
Multiplexing/Demultiplexing
Some error checking
Connectionless
No handshaking: just blasts away packets without any initial formality
No congestion control
Unreliable: just like IP, a best-effort protocol
Why use UDP then?
No connection establishment time: more efficient if reliability is not big issue
E.g. DNS uses UDP for better response time but HTTP uses TCP since reliability is critical (in fact this renders WWW rather world-wide wait)
No connection data (e.g. sequence numbers, buffers, congestion control parameter …) need to be stored in end systems
 maximum number of UDP clients is in general higher than TCP clients

15. UDP
Why UDP? (contd):
Smaller packet header: UDP: 3 bytes, TCP: 20 bytes
Better for real-time applications:
They require minimum data rate (in TCP they cannot control that because TCP waits for ACKs, delay them because of congestions, etc.)
These applications tolerate some data loss
They can enhance UDP service at will
Examples of applications that typically use UDP:
DNS: déjà vu
NFS: for efficiency
Internet telephony: need efficiency and tolerate some loss
Multimedia applications: need efficiency and tolerate some loss
Network management applications: because they should run even if network is congested (if reliability and congestion control are difficult to achieve)
Some routing protocols: because they exchange messages periodically, so loss can be tolerated
Database clients: for efficiency
RPCs (small request/reply pairs for idempotent operations)

16. UDP
UDP Header:
Size: 8 bytes; Source/Destination ports: each 2 bytes (up to 65,535, are reserved), Total length: of datagram, Checksum: 1’s complement (see Chapter 3)
Why redo error control (checksums) in transport layer?
Because layer-2 error control applies only to links, and some links may not have
error control at all, and UDP is an Internet protocol that has no restrictions on used
links.
UDP header.

17.  Receiver gets data from ANY client
UDP
Demultiplexing in UDP:
A receiver (socket) is identified by (ipAddress, portAddress) (e.g. (m3, x) see below) only
Example:
socket
Other
Receiver
Receiver A B a b y x m1 m2 m3
(m1, a, m3, x)
(m2, b, m3, x)
Parts of UDP headers, both are demultiplexed to the correct receiver using the pair (m3, x)
 Receiver gets data from ANY client

18. The Internet Transport Protocol: TCP
TCP (Transmission Control Protocol):
Connection-oriented:
3-way handshake
TCP Connection is NOT:
Like TDM/FDM connection on layer 2
Nor like virtual circuits of layer 3
Why? Since only end systems (hosts) know about it (not hardware, routers)
TCP connections are reliable (e.g. TCP detects lost packets, orders packets, …)
TCP connections are full-duplex
TCP connections point-to-point (no multicasting is possible using TCP)
TCP connections are byte-oriented (byte streams)
E.g. client sends msg1 and msg2, server is able to read them as one message.
TCP allocates buffers in sender/receiver hosts:
Application data are first copied to the buffer and then “grabbed” by TCP to
encapsulate them into segments that are sent down to the network layer (at receiver,
TCP first copies data into buffer, and then delivers them to server).

19. TCP TCP Header: Size: >= 20 bytes Ports: each 2 bytes
Checksum: like in UDP
Sequence/Ack numbers: for reliable communication
Window size: for flow control (# of bytes a receiver is willing to accept)
Header Length: 4 bits (max. 15 words = 15x4 bytes = 60 bytes)
Options: e.g. if sender wants to negotiate max. segment with receiver, …
ACK bit: indicates that ACK number is valid (this is an ACK)
RST bit: reset connection
SYN bit: synchronize sequence numbers
FIN bit: tear down connection
PSH bit: Receiver should pass (push) data to upper layer immediately (in general not used)
URG bit: part of the data are urgent (where? urgent pointer) (in general not used )

20.  Receiver gets data from ONE client per connection
TCP
Demultiplexing in TCP:
A receiver (socket) is identified by (ipAddress of sender, portAddress of sender, ipAddress of receiver, portAddress of receiver) (e.g. (m1, p, m3, x) see below).
Example: A and B (on different machines) use same port number p.
Other
Receiver A B
Receiver p p m1 m2 m3
(m1, p, m3, x)
(m2, p, m3, x)
Parts of TCP headers, both are demultiplexed to the correct connection using the 2 quadruples
 Receiver gets data from ONE client per connection

21. TCP TCP Sequence and ACK numbers: Number of byte (not of segment)
Example:
Sender sends segments of 1000 bytes
 Sequence numbers: 0, 1000, 2000, …
ACK number is the next expected byte offset
 e.g. receiver gets segments 0 and 2000 only, it set ACK field to 1000 (missing one)
Reliable data transfer in TCP:
Recall IP does not guarantee data delivery, in-order delivery, nor integrity
TCP guarantees that, if data are delivered (which is best-effort), then they are:
in-order, without gap, without duplication, not corrupted
TCP flow control and error recovery:
Hybrid of Go-back-N and Selective Repeat based on sliding windows (see Chapter 3)

22. TCP TCP Congestion Control:
Needed because IP provides no explicit feedback to end systems regarding congestion control (recall IP routers drops packets if congestion is detected)
TCP assumes a congestion if it timeouts or it receives NAKs (in fact there are no NAKs, but a repeated ACK is considered a NAK)
TCP congestion heuristics: Additive Increase Multiplicative Decrease (AIMD)
If congested, rate is halved (but never below some threshold T)
rate := max(T, rate/2)
If relieved, rate increases by T
rate := rate + T
(T = Maximum segment size / estimated round trip delay)
 AIMD in dependence of time is (almost) a sawtooth curve
Slow (or quick?) start: Initially, rate is set to T, but it increases exponentially after each round trip time. When losses occur (congestion), rate is decreased again.
In reality, algorithm is slightly more complex. TCP distinguishes between the event “timeout” and the event “NAK received” and reacts on them differently.

23. TCP
Fairness:
TCP tries to divide available network bandwidth evenly among current connections using the network.
However, the loophole is that applications can use parallel connections and have more share of the bandwidth.
 Web browsers use parallel connections to speed up communication
TCP/UDP in wireless networks (term wireless TCP/UDP is misleading):
In theory, transport layer protocols should be independent of the physical layer.
However, TCP protocol implementations mostly assume that a timeout signalizes a congestion. They then slow down.
Wireless networks are (still) very unreliable and may frequently loose packets (without congestion!). Thus, a timeout means that the sender should send the packet again and as soon as possible. In fact, we have here the opposite effect: the sender should speed up.
In practice, problem is worse, since some parts of network may be wired and other parts wireless.
In UDP, also the same problem, since in practice users expect UDP to be reliable (even if it is not).
Unsatisfactory solutions exist (see book)
T/TCP (Transactional TCP):
TCP optimized for transaction processing (less messages for connection setup/release)

24. TCP Some TCP-based Applications: Port Protocol Use 21 FTP
File transfer 23
Telnet
Remote login 25
SMTP 69
TFTP
Trivial File Transfer Protocol 79
Finger
Lookup info about a user 80
HTTP
World Wide Web
110
POP-3
Remote access
119
NNTP
USENET news