SMUCSE 4344 transport layer

SMUCSE 4344 transport layer end-to-end protocols –transport code runs only on endpoint hosts encapsulates network communications –app layer sees only simple transport primitives connectionless service connection-oriented service –establishment, data transfer, release

SMUCSE 4344 transport layer in situ transport entities/protocol handlers

SMUCSE 4344 challenges of “best effort” network layer dropped packets reordered packets duplicated packets finite sized packets packets delivered after long delay

SMUCSE 4344 services provided by transport layer guaranteed message delivery in-order message delivery no more than one copy of each message messages of arbitrary size sender/receiver synchronization receiver-applied flow control multiplexed end-to-end flows

SMUCSE 4344 transport protocol “suite” a transport protocol need not do all of these things we merely ask that, if required, a transport protocol be available to do at least some of these things and, that a suite of transport protocols cover all of these things in aggregate

SMUCSE 4344 protocol unit nesting for transmission TPDUs sometimes called “segments”

SMUCSE 4344 transport connection basis for multiplexing end-to-end messages TSAP: transport service access point

SMUCSE 4344 connection establishment clients requesting available service process server on “well-known” TSAP calls desired service process, and hands off connection

SMUCSE 4344

SMUCSE 4344 intro to Internet transport layer Internet Protocol (IP, network layer) provides unreliable datagram service between hosts transport protocols –end-to-end delivery between connection endpoints e.g., processes or programs User Datagram Protocol (UDP) –datagram service (best effort) Transmission Control Protocol (TCP) –reliable data delivery

SMUCSE 4344 UDP does not improve on best effort delivery checksum multiplexes messages –multiple process endpoints per host –keeps concurrent end-to-end messages separate host process ID + endpoint process ID –port (TSAP or “mailbox”) –IP port field: 16 bits, 64K available ports transport message ID: –((source IP, port ID), (sink ID, port ID))

SMUCSE 4344 TCP TCP is most widely used transport protocol provides reliable data delivery by using IP unreliable datagram delivery compensates for loss, delay, duplication, and similar problems in Internet components reliable delivery is high-level, familiar model for construction of applications

SMUCSE 4344 features of TCP connection oriented –application requests connection to destination and then uses connection to deliver data to transfer data point-to-point –a TCP connection has two endpoints reliability –TCP guarantees data will be delivered without loss, duplication, or transmission errors

SMUCSE 4344 full duplex –the endpoints of a TCP connection can exchange data in both directions simultaneously stream interface –application delivers data to TCP as a continuous stream, with no record boundaries; TCP makes no guarantees that data will be received in same blocks as transmitted reliable connection startup –three-way handshake guarantees reliable, synchronized startup between endpoints

SMUCSE 4344 graceful connection shutdown –TCP guarantees delivery of all data after endpoint shutdown by application Application process Write bytes TCP Send buffer Segment Transmit segments Application process Read bytes TCP Receive buffer … ……

SMUCSE 4344 connection establishment TCP uses three-way handshake for reliable connection establishment and termination –host 1 sends segment with SYN bit set and random sequence number –host 2 responds with segment with SYN bit set, acknowledgement to Host 1 and random sequence number –host 1 responds with acknowledgement

SMUCSE 4344 connection establishment and termination Active participant (client) Passive participant (server) SYN, SequenceNum = x SYN + ACK, SequenceNum = y, ACK, Acknowledgment = y + 1 Acknowledgment = x + 1

SMUCSE 4344 IP for data delivery TCP uses IP for data delivery (like UDP) endpoints are identified by ports allows multiple connections on each host IP treats TCP like data and does not interpret any contents Internet routers only look at IP header to forward datagrams TCP at destination interprets TCP messages

SMUCSE 4344 link layer vs. transport layer both offer “end-to-end” service between endpoints –error control, flow control, sequencing transport layer complications –addressing, connection mgt, packets wandering subnet

SMUCSE 4344 transport layer (vs. data link layer) potentially connects many different hosts –need explicit connection establishment and termination potentially different RTT –need adaptive timeout mechanism potentially long delay in network –need to be prepared for arrival of very old packets potentially different capacity at destination –need to accommodate different node capacity potentially different network capacity –need to be prepared for network congestion

SMUCSE 4344 reliable delivery using TCP TCP can recover from –lost packets –duplicate packets –delayed packets –corrupted data –transmission speed mismatches –congestion –system reboots

SMUCSE 4344 lost packets TCP uses positive acknowledgement with retransmission to achieve reliable data delivery recipient sends acknowledgment control messages (ACK) to sender to verify successful receipt of data sender sets timer when data transmitted; if timer expires before ACK arrives, sender retransmits (with new timer)

SMUCSE 4344 setting of delay critical, done dynamically –timeout should be based on round trip time (RTT) –sender picks retransmission timeout (RTO) based on previous RTTs –specific method is called adaptive retransmission algorithm

SMUCSE 4344 adaptive retransmission (simplified) measure SampleRTT for each segment/ ACK pair compute weighted average of RTT –EstRTT = (  x EstRTT ) + (  x SampleRTT ) –where  +  = 1 –0.8 <  < 0.9 –0.1 <  < 0.2 set timeout based on EstRTT –TimeOut = 2 x EstRTT current implementations account for RTT variance

SMUCSE 4344 segments and sequence numbers application delivers arbitrarily large chunks of data to TCP as a “byte stream” TCP breaks data into segments, each of which fits into an IP datagram original stream is numbered by bytes segment contains sequence number of data bytes ACK does not acknowledge segments per se receiver ACKs segment with sequence number of acknowledged data so, one ACK can acknowledge many segments

SMUCSE 4344 segment format

SMUCSE 4344 TCP flow control TCP uses sliding window for flow control receiver specifies window –called window advertisement –specifies which bytes in data stream can be sent –carried in the segment along with ACK sender can transmit any bytes, in any size segment, between last acknowledged byte and within window size

SMUCSE 4344 issues related to advertisement sliding window can result in transmission of many small segments, as follows if receiver window is full, and receiving application consumes a few data bytes, receiver will advertise small window sender will immediately send small segment to fill window

SMUCSE 4344 wastes processing cycles, network bandwidth solutions: –receiver delays advertising new window –sender delays sending data when window is small

SMUCSE 4344 transport wrinkle: RPC remote procedure calls (RPCs) –client call (with parameters), server return values –needs reliable delivery, process-to-process –TCP connection machinery overhead is too much must support: –large messages –synchronization of request/reply –delivery to/from correct host processes SunRPC, DCE-RPC (Open Softward Fdn.)