1 Transport Layer Abusayeed Saifullah CS 5600 Computer Networks These slides are adapted from Kurose and Ross
2 Transport Layer our goals: v understand principles behind transport layer services: multiplexing, demultiplexing reliable data transfer flow control congestion control v learn about Internet transport layer protocols: UDP: connectionless transport TCP: connection-oriented reliable transport TCP congestion control
3 Roadmap 1 transport-layer services 2 multiplexing and demultiplexing 3 connectionless transport: UDP 4 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 5 principles of congestion control 6 TCP congestion control
4 Transport services and protocols v provide logical communication between app processes running on different hosts v transport protocols run in end systems send side: breaks app messages into segments, passes to layer rcv side: reassembles segments into messages, passes to app layer v more than one transport protocol available to apps Internet: TCP and UDP transport data link transport data link
5 Transport vs. layer v layer: logical communication between hosts v transport layer: logical communication between processes relies on, enhances, layer services household analogy: 12 kids in Ann s house sending letters to 12 kids in Bill s house: Ann and Bill collect and distribute mails for their respective houses v hosts = houses v processes = kids v app messages = letters in envelopes v transport protocol = Ann and Bill who demux to inhouse siblings v -layer protocol = postal service
6 Internet transport-layer protocols v reliable, in-order delivery (TCP) congestion control flow control connection setup v unreliable, unordered delivery: UDP no-frills extension of best-effort IP v services not available: delay guarantees bandwidth guarantees transport data link data link data link data link data link data link data link data link transport data link
7 Roadmap 1 transport-layer services 2 multiplexing and demultiplexing 3 connectionless transport: UDP 4 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 5 principles of congestion control 6 TCP congestion control
8 Multiplexing/demultiplexing multiplexing at sender: handle data from multiple sockets, add transport header (later used for demultiplexing) demultiplexing at receiver: use header info to deliver received segments to correct socket P3 transport link P1 P2 transport link P4 transport link socket process
9 Multiplexing Multiplexing requires that v Sockets have unique identifiers v Each transport layer segment has special fields that indicate the socket to which the segment is to be delivered UDP socket is identified by v 2-tuple: destination IP, destination port TCP socket is identified by v 4-tuple: dest IP, dest port, source IP, source port
10 How demultiplexing works v host receives IP datagrams each datagram has source IP address, destination IP address each datagram carries one transport-layer segment each segment has source, destination port number v host uses IP addresses & port numbers to direct segment to appropriate socket 32 bits source port # dest port # other header fields data (payload) TCP/UDP segment format
11 Connectionless demultiplexing v recall: created socket has host-local port #: DatagramSocket mysocket1 = new DatagramSocket(12534); v recall: when creating datagram to send into UDP socket, must specify destination IP address destination port # v when host receives UDP segment: checks destination port # in segment directs UDP segment to socket with that port # IP datagrams with same dest. port #, but different source IP addresses and/ or source port numbers will be directed to same socket at dest
12 Connectionless demux: example DatagramSocket mysocket2 = new DatagramSocket (9157); P3 transport link DatagramSocket serversocket = new DatagramSocket (6428); P1 transport link DatagramSocket mysocket1 = new DatagramSocket (5775); P4 transport link source port: 6428 dest port: 9157 source port:? dest port:? source port: 9157 dest port: 6428 source port:? dest port:?
13 Connection-oriented demux v TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number v demux: receiver uses all four values to direct segment to appropriate socket v server host may support many simultaneous TCP sockets: each socket identified by its own 4-tuple v web servers have different sockets for each connecting client non-persistent HTTP will have different socket for each request
14 Connection-oriented demux: example P3 transport link P4 P5 transport link P6 server: IP address B P2 P3 transport link host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: A,9157 dest IP, port: B,80 three segments, all destined to IP address: B, dest port: 80 are demultiplexed to different sockets source IP,port: C,5775 dest IP,port: B,80 source IP,port: C,9157 dest IP,port: B,80 host: IP address C
15 Connection-oriented demux: example threaded server P3 transport link P4 transport link server: IP address B P2 P3 transport link host: IP address A source IP,port: B,80 dest IP,port: A,9157 source IP,port: C,5775 dest IP,port: B,80 host: IP address C source IP,port: A,9157 dest IP, port: B,80 source IP,port: C,9157 dest IP,port: B,80
16 Roadmap 1 transport-layer services 2 multiplexing and demultiplexing 3 connectionless transport: UDP 4 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 5 principles of congestion control 6 TCP congestion control
17 UDP: User Datagram Protocol [RFC 768] v no frills, bare bones Internet transport protocol v best effort service, UDP segments may be: lost delivered out-of-order to app v connectionless: no handshaking between UDP sender, receiver each UDP segment handled independently of others v UDP use: streaming multimedia apps (loss tolerant, rate sensitive) RIP SNMP v reliable transfer over UDP: add reliability at layer -specific error recovery!
18 UDP: segment header 32 bits source port # dest port # length data (payload) checksum UDP segment format length, in bytes of UDP segment, including header why is there a UDP? v no connection establishment (which can add delay) v simple: no connection state at sender, receiver v small header size no congestion control à high loss rate
19 UDP checksum Goal: detect errors (e.g., flipped bits) in transmitted segment sender: v treat segment contents, including header fields, as sequence of 16-bit integers v checksum: addition (one s complement sum) of segment contents v sender puts checksum value into UDP checksum field receiver: v compute checksum of received segment v check if computed checksum equals checksum field value: NO - error detected YES - no error detected.
20 Internet checksum: example example: add two 16-bit integers wraparound sum checksum Note: when adding numbers, a carryout from the most significant bit needs to be added to the result
21 Roadmap 1 transport-layer services 2 multiplexing and demultiplexing 3 connectionless transport: UDP 4 connection-oriented transport: TCP segment structure reliable data transfer flow control connection management 5 principles of congestion control 6 TCP congestion control
22 TCP: Overview RFCs: 793,1122,1323, 2018, 2581 v point-to-point: one sender, one receiver v reliable, in-order byte steam: v pipelined: TCP congestion and flow control set window size v full duplex data: bi-directional data flow in same connection MSS: maximum segment size v connection-oriented: handshaking (exchange of control msgs) inits sender, receiver state before data exchange v flow controlled: sender will not overwhelm receiver
23 TCP segment structure URG: urgent data (generally not used) ACK: ACK # valid PSH: push data now (generally not used) RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP) 32 bits source port # dest port # head len sequence number acknowledgement number not used U A P R S F checksum receive window data (variable length) Urg data pointer options (variable length) counting by bytes of data (not segments!) # bytes rcvr willing to accept
24 TCP reliable data transfer v TCP creates rdt service on top of IP s unreliable service pipelined segments cumulative acks single retransmission timer v We have studied the protocols in data link layer Similar
25 TCP flow control v receiver advertises free buffer space by including rwnd value in TCP header of receiver-to-sender segments RcvBuffer size set via socket options (typical default is 4096 bytes) many operating systems autoadjust RcvBuffer v sender limits amount of unacked ( in-flight ) data to receiver s rwnd value v guarantees receive buffer will not overflow RcvBuffer rwnd to process buffered data free buffer space TCP segment payloads receiver-side buffering
26 TCP Connection Management before exchanging data, sender/receiver handshake : v agree to establish connection (each knowing the other willing to establish connection) v agree on connection parameters connection state: ESTAB connection variables: seq # client-to-server server-to-client rcvbuffer size at server,client connection state: ESTAB connection Variables: seq # client-to-server server-to-client rcvbuffer size at server,client Socket clientsocket = newsocket("hostname","port number"); Socket connectionsocket = welcomesocket.accept();
27 Agreeing to establish a connection 2-way handshake: Let s talk OK ESTAB ESTAB Q: will 2-way handshake always work in? v retransmitted messages (e.g. req_conn(x)) due to message loss v can t see other side choose x ESTAB req_conn(x) acc_conn(x) ESTAB
28 TCP 3-way handshake client state LISTEN SYNSENT ESTAB choose init seq num, x send TCP SYN msg received SYNACK(x) indicates server is live; send ACK for SYNACK; this segment may contain client-to-server data SYNbit=1, Seq=x SYNbit=1, Seq=y ACKbit=1; ACKnum=x+1 ACKbit=1, ACKnum=y+1 choose init seq num, y send TCP SYNACK msg, acking SYN received ACK(y) indicates client is live server state LISTEN SYN RCVD ESTAB
29 TCP: closing a connection v Connection release is easy but needs care v Asymmetric release is the way the telephone system works: when one party hangs up, the connection is broken. v Symmetric release treats the connection as two separate unidirectional connections and requires each one to be released separately.
30 Asymmetric Release Abrupt disconnection with loss of data à needs better protocol
31 Symmetric release v Symmetric release does the job when each process has a fixed amount of data to send and clearly knows when it has sent it. v One can envision a protocol in which host 1 says I am done. Are you done too? If host 2 responds: I am done too. Goodbye, the connection can be safely released. v Unfortunately, this protocol does not always work: two-army problem.
32 Two-army problem
33 Two-army problem v A white army is encamped in a valley. v On both surrounding hillsides are blue armies. v The white army is larger than either of the blue armies alone, but together the blue armies are larger than the white army. v If either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be victorious.
34 Two-army problem v The blue armies want to synchronize their attacks. v However, their only communication medium is to send messengers on foot down into the valley, where they might be captured and the message lost (i.e., they have to use an unreliable communication channel). v The question is: does a protocol exist that allows the blue armies to win?
35 Two-army problem v Answer: no protocol exists that works. v Relevance to connection release substitute disconnect for attack. If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen.
36 solution to close a TCP connection v In practice, we can avoid this quandary by foregoing the need for agreement and letting each side independently decide when it is done. v client, server each close their side of connection send TCP segment with FIN bit = 1 v respond to received FIN with ACK on receiving FIN, ACK can be combined with own FIN v While this protocol is not infallible, it is usually adequate.
37 solution to close a TCP connection client state server state ESTAB ESTAB clientsocket.close() FIN_WAIT_1 FIN_WAIT_2 can no longer send but can receive data wait for server close FINbit=1, seq=x ACKbit=1; ACKnum=x+1 can still send data CLOSE_WAIT TIMED_WAIT timed wait FINbit=1, seq=y ACKbit=1; ACKnum=y+1 can no longer send data LAST_ACK CLOSED CLOSED