The Transport Layer = L4

Chapter 6 The Transport Layer = L4

Messages

Segments

Packets

Frames

Bits / Bytes L2-L3-L4 encapsulation

Transport layer sends segments in packets (in frames)

Segment Frame trailer

Segment Interactions L3-L4-L5 Transport layer offers connectionless (UDP) and connection- oriented (TCP) service to applications L4 vs. L3

L3 is “hop-by-hop”, operating on the source host, destination host, and on all the routers in the network. L4 is “end-to-end”, operating only on the source host and destination host! • The users have no control over the network, esp. when there are multiple networks in between • L3 does not retransmit pkts. (it just sends error notifications via ICMP), i.e. it is unreliable • L4 provides end-to-end reliability, i.e. it provides reliable service to L5 • Yes, L4 also provides unreliable service (UDP), but that has very little functionality. Simplified Transport Service Primitives (offered by L4 to L5) Applications (L5) invoke these primitives to implement connection- oriented transport service. Scenario: one server and multiple clients: – Each client calls connect, send, receive, disconnect – Server calls listen, receive, send, disconnect

Segment High-level state diagram of TCP connection life-cycle

Dashed lines show server Solid lines show client state sequence state sequence

Transitions in italics are due to segment arrivals. Real-life Transport Service Primitives Berkeley Sockets Very widely used primitives, started with TCP on UNIX • A “socket” is a transport endpoint, analogous to a hardware socket • Like simple set plus SOCKET, BIND, and ACCEPT

Always executed in this order by a server

Unlike the simplified model, here LISTEN is not blocking!

Same as Returns file handle which can Symmetrical, i.e. both client and DISCONNECT! be used for regular R/W server have to release their side Real-life Transport Service Primitives Berkeley Sockets Real-life Transport Service Primitives Berkeley Sockets Client side

No need to BIND, since address

• Remainder of Sec. 6.1.4 (Internet File Server) • Sec. 6.2 • Sec. 6.3 6.4 UDP • RFC 768 – User Datagram Protocol • Connectionless service! • Encapsulation and little else  • No flow ctrl., congestion ctrl., or retransmissions • Typical app.: Client-server w/short requests and replies (e.g. DNS)

If error, the client application times out and sends the request again!

The UDP header. 6.5 TCP Initially defined in RFC 793 “Transmission Control Protocol”, followed by many subsequent RFCs • there is even a guide: RFC 4614! Provides connection-oriented service, with: • flow ctrl. • congestion ctrl. • retransmissions • reordering Typical app.: Client-server with large replies (e.g. FTP) Functions performed by TCP

 Break the App stream into TCP payloads of a given maximum size (Usually 1460 Bytes – Why?).  Reorder the incoming segments (they may be out of order).  Reassembly the Application (L5) stream.  Retransmit lost segments.  Flow ctrl.  Congestion ctrl. The TCP Service Model

The Application (L5) interacts with the TCP entity through the sockets API – sockets for short. A TCP socket is uniquely identified by the pair [TCP port, IP addr.]. The TCP ports in the range 0-1023 are known as well-known ports (RFC 1700), e.g.:

A pair of sockets uniquely identifies a TCP connection. The TCP Service Model All TCP connections are: • Point-to-point: no Mcast/Bcast • Full duplex: both client and server can send data over the same conn. • Byte stream: the TCP entity keeps track of individual Bytes!

Byte stream example:

(a) Four 512-byte segments sent as separate IP datagrams. (b) The 2048 bytes of data delivered to the application in a single READ CALL. The TCP Segment Header At least the 20-byte IPv4 hdr. goes here (maybe IP options as well).

of the first data byte in this segment.

Next byte expected Ignored if ACK=0

6 bits unused Must be zero! If zero, it means “Don’t send me anything for now”.

Ignored if URG=0

not necessarily multiple of 4 byte.

Same as IP hdr. length (takes into account options) If SYN=1, the sequence number is the (random) initial seq.# (ISN) and the first data Byte is ISN+1. SYN = 1 → is used for connection request and reply FIN = 1 → sender has no more data to send (but can accept data, i.e. asymmetric connection release) Segments with SYN = 1 or FIN = 1 carry no data, but they still consume one unit of seq.# space (so they can be ACK-ed unambiguously).

RST = 1 → refuse attempt to open connection URG (and the Urgent pointer): • Points to the byte after the end of the urgent data. (It’s up to App to figure out where the urgent data started!) • Is a positive offset from the seq.# of the current segment. • Rarely used, and discouraged today. Data sent by App may be sent immediately or buffered by TCP and sent later (why? Nagle’s algorithm to avoid “tinygrams” - p.566) • Some Apps. want data to be sent immediately (e.g. telnet → short, interactive messages) → PSH • But the socket API does not have a function to set it! • Like URG, rarely used today.

ACK is used in conjunction to the ACK Number field - see Connection Establishment slides below. Options: MSS (Maximum Segment Size)

Using large segments is more efficient than using small ones because the 20-byte header can be amortized over more data. However, small hosts may not be able to handle very large segments. Options: MSS (Maximum Segment Size)

If the MSS option is not used during connection establishment, MSS defaults to 556 byte (536 payload). All Internet hosts are required to accept TCP segments of at least 556 Bytes

Contrary to popular belief, MSS is not negotiated, but simply announced by each side. • The communicating hosts will use the smallest of the two values announced. • MSSes can be different in the two directions of a connection! 6.5.5 Conn. establishment: The “3-way handshake”

Server: LISTEN Client: CONNECT

6-31 Server: ACCEPT Client: SEND DATA

Why x+1 and y+1 if no real data has been sent yet? Note that the sequence numbers: • Are different between the two directions. • Are incremented by one even when no data has been sent yet - this allows the initial handshake segments to be ACK-ed! Two connections are established - one in each direction! If no socket is open on the server with the respective TCP port, the server rejects the connection with a segment having RST set to one. What can go wrong with the “3-way handshake”

(b) Call collision: only 1 connection is established! (the one with SEQ number y) 6.5.6 Connection release Asymmetric, b/c there are usually two conn. open, one in each direction (i.e. a connection can be half-open). To release on both sides, two FIN and two ACK are needed (a.k.a. four-way handshake). Connection release

It is also possible to terminate the connection by a 3-way handshake, when A sends a FIN and B replies with a FIN & ACK (combines 2 steps into one), then host A replies with an ACK: Connection release

If FIN is not ACK-ed within a certain time limit, the connection is released unilaterally. The other side times out later because it does not hear any more responses.

The 2-army problem (pp.518-21) proves that no synchronization algorithm can be 100% safe: SKIP 6.5.7 Connection mgmt. Finite State Machine 6.5.8 Window Management Receiver has a 4096-byte buffer. Sender transmits a 2048-byte segment (w/o errors), the receiver acknowledges the segment. However, since it now has only 2048 bytes of buffer space (until the application removes some data from the buffer), it will advertise a window of 2048 starting at the next byte expected.

6.5.8 Window Management Read the remainder of this section and take notes:  What is a Window Probe and in what scenario is it needed?  What are Delayed Acknowledgements? How are they used to reduce overhead?  What is Nagle’s algorithm?  What is the Silly window Syndrome? What is Clarke’s algorithm that addresses it?  What are Cumulative Acknowledgements? SKIP the rest of Ch.6, starting with 6.5.9 (p.568)

This is the end of the material for our class