Chapter 6 The Transport Layer

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

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

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.

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

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

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

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.

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

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.

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

(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.

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.

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

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)

UDP UDP Header: Size: 8 bytes; Source/Destination ports: each 2 bytes (up to 65,535, 0..1023 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.

 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

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).

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 )

 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

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)

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.

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)

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