Transport Layer Foreleser Carsten Griwodz Email griffifi uio

Transport Layer Foreleser: Carsten Griwodz Email: griff@ifi. uio. no 24. Mar. 2004 1 INF-3190: Transport Layer

Transport Protocols: UDP 24. Mar. 2004 2 INF-3190: Transport Layer

UDP - User Datagram Protocol • Specification • • UDP is a simple transport protocol • • Unreliable Connectionless Message-oriented => UDP is mostly IP with short transport header • • • RFC 768 Source and destination port Ports allow for dispatching of messages to receiver process Characteristics • No flow control • • No error control or retransmission • • Application may transmit as fast as it can / want and the network permits No guarantee about packet sequencing Packet delivery to receiver not ensured Possibility of duplicated packets May be used with broadcast / multicasting and streaming 24. Mar. 2004 3 INF-3190: Transport Layer

UDP: Message Format Version IHL Type PRE of service To. S Total length Identification DM Fragment offset Time to live Protocol Header checksum Source address Destination Address Options Source port Destination port Packet length Checksum IP header UDP header Data • Source port • • • Optional 16 bit sender identification Response may be sent there • • Destination port • Packet length • Receiver identification Checksum • • 24. Mar. 2004 4 In byte (including UDP header) Minimum: 8 (byte) i. e. header without data Optional Checksum of header and data for error detection INF-3190: Transport Layer

UDP: Message Format – Checksum • Purpose • • Same algorithm as IP • • Error detection (header and data) One’s complement of sum of 16 -bit halfwords in one’s complement arithmetic UDP checksum includes • • • UDP header (checksum field initially set to 0) Data Pseudoheader • Part of IP header • • • source IP address destination IP address Protocol length of (UDP) data 0000 Source address Destination Address Protocol UDP segment length Allows to detect misdelivered UDP messages Use of checksum optional • i. e. , if checksum contains only "0"s, it is not used • 24. Mar. 2004 Transmit 0 x. FFFF if calculated checksum is 0 5 INF-3190: Transport Layer

UDP: Ranges of Application • Benefits of UDP • • Needs very few resources (in endsystems, in each data unit) No connection establishment (hence, no overhead, faster transmission) Simplementation possible (e. g. suitable for boot PROM) Applications can precisely control • • Packet flow Error handling / reliability Timing Problems of UDP • No flow control • • Packets can be lost because receiving application is too slow No congestion control • 24. Mar. 2004 No reaction to network overload 6 INF-3190: Transport Layer

UDP: Ranges of Application • Suitable • For simple client-server interactions, i. e. typically • • • When delay is worse than packet loss and duplication • • 1 request packet from client to server 1 response packet from server to client Video conferencing IP telephony Gaming Used by e. g. • • DNS: SNMP: BOOTP: TFTP: NFS: NTP: RTP: Domain Name Service ¹ Simple Network Management Protocol Bootstrap protocol Trivial File Transfer Protocol Network File System ¹ Network Time Protocol ¹ Real-time Transport Protocol ¹ ¹ can also be used with TCP 24. Mar. 2004 7 INF-3190: Transport Layer

Transport Protocols: TCP 24. Mar. 2004 8 INF-3190: Transport Layer

TCP - Transmission Control Protocol n TCP is the main transport protocol of the Internet n History n n n RFC 793: originally RFC 1122 and RFC 1323: errors corrected, enhancements implemented Motivation: network with connectionless service n Packets and messages may be n n duplicated, in wrong order, faulty i. e. , with such service only, each application would have to provide recovery n n Network or service can n n error detection and correction impose packet length define additional requirements to optimize data transmission i. e. , application would have to be adapted TCP provides n Reliable end-to-end byte stream over an unreliable internetwork 24. Mar. 2004 9 INF-3190: Transport Layer

What is TCP? n TCP is n n n A transport protocol specification Not a piece of software TCP specifies n n Data and control information formats Procedures for n n As a primary abstraction n flow control error detection and correction connect and disconnect a connection not just the relationships of ports (as a queue, like UDP) TCP does not specify n n The interface to the application (sockets, streams) Interfaces are specified separately: e. g. Berkeley Socket API, WINSOCK 24. Mar. 2004 10 INF-3190: Transport Layer

TCP in Use & Application Areas n Each machine supporting TCP has a TCP transport entity n n TCP transport entity manages n n n Library procedure User process Part of kernel TCP streams Interfaces to IP layer TCP transport entity on sending side n n Accepts user data streams for local processes Splits them into pieces <= 64 KB n Often 1460 bytes n n n Sends each piece as separate IP datagram TCP transport entity on receiving side n n n (to fit into single Ethernet frame with IP and TCP headers) Gets TCP data from packets received at host Reconstructs original byte streams TCP must ensure reliability n IP layer doesn’t guarantee that packets will be delivered properly / in order (TCP must handle this, e. g. timeout and retransmit / reorder) 24. Mar. 2004 11 INF-3190: Transport Layer

TCP in Use & Application Areas n Benefits of TCP n n Reliable data transmission Efficient data transmission despite complexity n n Can be used with LAN and WAN for n n n low data rates (e. g. interactive terminal) and high data rates (e. g. file transfer) Disadvantages when compared with UDP n Higher resource requirements n n buffering, status information, timer usage Connection set-up and disconnect necessary n n (up to 8 Mbps on 10 Mbps ethernet) even with short data transmissions Applications n n File transfer (FTP) Interactive terminal (Telnet) E-mail (SMTP) X-Windows 24. Mar. 2004 12 INF-3190: Transport Layer

TCP Characteristics n Data stream oriented n n n Unstructured byte stream n n n TCP transfers serial byte stream Maintains sequential order Application often has to transmit more structured data TCP does not support such groupings into (higher) structures within byte stream Buffered data transmission n Byte stream not message stream: message boundaries are not preserved n n no way for receiver to detect the unit(s) in which data were written For transmission the sequential data stream is n n Divided into segments Delayed if necessary (to collect data) n 24. Mar. 2004 For more efficient transmission (e. g. network utilization) 13 INF-3190: Transport Layer

TCP Characteristics n Virtual connection n n Two-way communications (fully duplex) n n Data may be transmitted simultaneously in both directions over a TCP connection Point-to-point n n Connection established between communication parties before data transmission Each connection has exactly two endpoints Reliable n Fully ordered, fully reliable n n 24. Mar. 2004 Sequence maintained No data loss, no duplicates, no modified data 14 INF-3190: Transport Layer

TCP Characteristics • Error detection • • Piggybacking • • Control information and data can be transmitted within the same segment Out-of-band data: expedited data • • • Through checksum Important information sent to receiver i. e. should get to receiver’s application before data that was sent earlier PUSH operation • • Data is not stored in a buffer Sent immediately and immediately made available to application on receiver’s end • • example <CR> end of line at terminal emulation Urgent flag • Send and transfer data to application immediately • 24. Mar. 2004 example <Crtl C> arrival interrupts receiver’s application 15 INF-3190: Transport Layer

TCP Characteristics • No broadcast • • • No multicasting • • Group addressing not possible No Qo. S parameters • • No possibility to address all applications With connect, however, not necessarily sensible Not suited for different media characteristics No real-time support • • No correct treatment / communications of audio or video possible E. g. no forward error correction 24. Mar. 2004 16 INF-3190: Transport Layer

Connection – Addressing Connection Process indicates that it would accept connect request Active open n n Port Passive open n n Port Process requests a connection Addressing n Port number + protocol identification n n clearly identifies entity in the ES IP address n 24. Mar. 2004 clearly identifies ES 17 INF-3190: Transport Layer

Connection – Addressing • TCP service obtained via service endpoints on sender and receiver • • Typically socket Socket number consists of • • • Transport Service Access Point • • IP address of host and 16 -bit local number (port) Port TCP connection is clearly defined by a quintuple consisting of • • • Server offers (IP addr/port/TCPid) (1. 1/1/6) (2. 2/2/1. 1/1/6) 1. 1 2. 2 1 IP address of sender and receiver Port address of sender and receiver TCP protocol identifier 2 3 (2. 2/3/1. 1/1/6) • Applications can use the same local ports for several connections 24. Mar. 2004 18 4 3. 3 (IP addr sender/port sender/ IP addr recv/port recv/TCPid) (3. 3/4/1. 1/1/6) INF-3190: Transport Layer

Connection Establishment n One passive & one active side n n Server: wait for incoming connection using LISTEN and ACCEPT Client: CONNECT (specifying IP addr. and port, max. TCP segment size) Host 1 Client Host 2 Server send SYN(SEQ=x) receive SYN n Three-Way-Handshake n n Connecting through 3 packets receive SYN+ACK Comments n When establishing a connection n initial sequence numbers of both partners are also exchanged and acknowledged initial seq. # is not 0 send SYN(SEQ=x+1) ACK(SEQ=y+1) SYN segment consumes one byte of sequence space n 24. Mar. 2004 time in order to be acknowledged unambiguously 19 send SYN(SEQ=y) ACK(SEQ=x+1) receive SYN+ACK time INF-3190: Transport Layer

Connection Establishment n Comments n If on server side no process is waiting on port (no process did LISTEN) n n Host 1 Client send SYN(SEQ=x) Reply segment with RST bit set is sent to reject connection attempt receive SYN Process listening on port may accept or reject send RST time 24. Mar. 2004 Host 2 No server 20 time INF-3190: Transport Layer

Connection Establishment n Call collision n Host 1 Client & Server Still only one single connection will be established even when n both partners actively try to establish a connection simultaneously send SYN(SEQ=x) send SYN(SEQ=y) receive SYN send SYN(SEQ=x) ACK(SEQ=y+1) receive SYN+ACK time 24. Mar. 2004 21 Host 2 Client & Server send SYN(SEQ=y) ACK(SEQ=x+1) receive SYN+ACK time INF-3190: Transport Layer

Connection Release n Connection release for pairs of simplex connections n n Connection release by either side sending a segment with FIN bit set n n n each direction is released independently of other no more data to be transmitted when FIN is acknowledged, this direction is shut down for new data Directions are released independently n n other direction may still be open full release of connection if both directions have been shut down 24. Mar. 2004 22 INF-3190: Transport Layer

Connection Release n Systematic disconnect by 4 segments n between 2 nd and 3 rd n n host 2 can still send data to host 1 n n receive FIN first ACK and second FIN may be contained in same segment (3 segments instead of 4) Connection interrupt: Opposite side cannot transmit data anymore immediate acknowledgement, release of all resources data in transit may be lost 24. Mar. 2004 Host 2 Peer send FIN(seq=x) Reduction of packet number possible n n Host 1 Peer receive ACK+FIN send ACK(SEQ=y+1) time 23 send ACK(SEQ=x+1) send FIN(SEQ=y) ACK(SEQ=x+1) receive ACK time INF-3190: Transport Layer

Connection Management Modelling n States State Description CLOSED No connection is active or pending LISTEN Server is waiting for an incoming call SYN RCVD Connection request has arrived, wait for ACK SYN SENT Application has started to open a connection ESTABLISHED Normal data transfer state FIN WAIT 1 Application has said it is finished FIN WAIT 2 The other side has agreed to release TIMED WAIT Wait for all packets to die off CLOSING Both sides have tried to close simultaneously CLOSE WAIT The other side has initiated a release LAST ACK Wait for all packets to die off 24. Mar. 2004 24 INF-3190: Transport Layer

States CLOSED Timeout Se nd SY N Y K LISTEN S C N A v Rec d SYN S end RST Sen SY v c N Re Recv SYN Send SYN ACK SYN RCVD Rec v ACK SYN CK v c Re end A S ESTABLISHED Send FIN SYN SENT IN F end Recv FIN Send ACK CLOSE WAIT LAST ACK Send FIN S FIN WAIT 1 Recv ACK FIN WAIT 2 24. Mar. 2004 Recv FIN Send ACK Rec v. F Sen IN ACK d AC K Recv FIN Send ACK CLOSING Recv ACK TIME WAIT 25 Timeout INF-3190: Transport Layer

Typical State Sequence of a TCP Client CLOSED LISTEN SYN RCVD Send SYN Recv SYN, ACK Send ACK SYN SENT ESTABLISHED CLOSE WAIT LAST ACK Send FIN WAIT 1 CLOSING Recv ACK FIN WAIT 2 24. Mar. 2004 Recv FIN, Send ACK TIME WAIT 26 Timeout INF-3190: Transport Layer

Typical State Sequence of a TCP Server CLOSED Timeout LISTEN Recv SYN Send SYN, ACK SYN SENT SYN RCVD Recv ACK ESTABLISHED CLOSE WAIT Recv FIN, Send ACK FIN WAIT 1 CLOSING FIN WAIT 2 TIME WAIT 24. Mar. 2004 27 LAST ACK Send FIN INF-3190: Transport Layer

TCP Packets and Fragments 24. Mar. 2004 28 INF-3190: Transport Layer

TCP - Protocol, PDU Format, Segments • TCP/IP Header Format Version IHL Type PRE of service To. S Total length Identification DM Fragment offset Time to live Protocol Header checksum Source address Destination Address Options Source port Destination port Sequence number Piggyback acknowledgement THL unused U A P R S F Window Checksum Urgent pointer Options (0 or more 32 bit words) TCP header THL – TCP header length U: URG – urgent A: ACK – acknowledgement P: PSH – push R: RST – reset S: SYN – sync F: FIN – finalize Data 24. Mar. 2004 IP header 29 INF-3190: Transport Layer

Segments • TCP entitites exchange data in form of segments • TCP segment consists of • • • Fixed 20 byte header (plus optional part) Zero or more data bytes TCP software (entity) decides • Segment size to be used • • • Data from several writes can be accumulated into one segment or Data from one write can be split into several segments Limits • • Each segment (including TCP header) must fit into 65515 byte IP payload Segment must fit into maximum transfer unit (MTU) of visited networks • • • 24. Mar. 2004 Each network may have MTU, depending on L 2 technology used Often 1500 byte (Ethernet payload size), typical upper bound on segm. Size Further on (if really needed) IP will "fragment" packets if they are too large for visited networks 30 INF-3190: Transport Layer

Identification of TCP-Packets i. e. Segments • A key feature • • Every byte on TCP connection has its own 32 -bit sequence number Separate sequence numbers used for • • Data Acknowledgements Window mechanism Remember • • 24. Mar. 2004 32 -bit sequence number space was big in early days of the Internet Nowadays, it can be consumed very fast 31 INF-3190: Transport Layer

Protocol with Flow Control • TCP uses: Sliding window protocol • Sender starts timer when it transmits segment • Receiving TCP entity sends back a segment • • • With data if any, otherwise without data Acknowledgment number equal to next sequence number it expects to receive If sender’s timer goes off before acknowledgement arrives • • 24. Mar. 2004 Segment is retransmitted Secondary interpretation for congestion control 32 INF-3190: Transport Layer

Segments, Fragmentation (and Reassembly) • Fragments • • • IP packets are split (if necessary) into fragments in order to adapt them to underlying networks IP does not reassemble Segments • TCP Data stream split into segments • • Segments sent as IP packets TCP reassembles segments and fragments 24. Mar. 2004 33 INF-3190: Transport Layer

Segments, Fragmentation (and Reassembly) ID 43 MF 0 FA 0 ID 43 MF 1 FA 0 TCP header + data (250 byte) 104 byte IP header: 20 byte ID 43 ID: Datagram Identification MF: More Fragments bit 0: no 1: yes FA: Fragment Offset n: n*8 byte MF 1 FA 13 104 byte IP header: 20 byte ID 43 MF 0 FA 26 42 byte IP header: 20 byte 24. Mar. 2004 34 INF-3190: Transport Layer

TCP Reliability and Ordering Timers 24. Mar. 2004 35 INF-3190: Transport Layer

Timer Management • • • Timer is set when segment is sent If ACK arrives before timer expires: timer is stopped If timer expires before ACK arrives: segment is retransmitted • • and new timer is set Question: How long should the timeout interval be? 24. Mar. 2004 36 Time out 0. 3 Probability • TCP uses several timers for different purposes Retransmission timer as most important one 0. 2 0. 1 0 10 20 30 40 50 Round trip time (msec) Closer to real situation 0. 3 Probability • Ideal situation 0. 2 Time out too short too long 0. 1 0 10 20 30 40 50 Round trip time (msec) INF-3190: Transport Layer

Timer Management • • Timeout after a certain time period Situation in the Internet: packet communication time may vary immensely • Timeout too short • • • Timeout too long • • • fast reaction due to any errors but correct packets retransmitted too slow reaction due to errors less additional traffic Better: adaptive timeout intervals • Timeout period (until retransmit) • • continuous adaptation to pre-calculated, expected waiting period Waiting period increases for each retransmission of the same segment 24. Mar. 2004 37 INF-3190: Transport Layer

Timer Management • Relevant parameters • RTT: Round Trip Time (or Round Trip Sample) • time between • • • sending of octet and the receiving of respective acknowledgment Timeout: initiates retransmission Algorithm (Jacobson, 1988) • a Smoothing factor • • • 0. . 1 0: 7/8 1: determines importance of the history only current/last value is relevant typical Value only old values are relevant b (later/today proportional to the average deviation) • • • 24. Mar. 2004 1: faster error correction 2: original value in implementations Comment: usually hard to define (as fixed value) 38 INF-3190: Transport Layer

RTT Calculation in Case of Error Recovery • • How to handle dynamic RTT estimation when segment must be resent? Situation: ambiguous measurement • • • t 1: retransmit initiated because of timeout t 2: acknowledgement arrives at the receiver’s Question • Does confirmation refer to • • 1. data which has previously been thought as being lost? or 2. data which has been sent last? Problem: no differentiation possible This influences the definition/parameter setting of the timeout • By the RTT measured 24. Mar. 2004 39 INF-3190: Transport Layer

RTT Calculation in Case of Error Recovery • • Situation: ambiguous measuring 1 st assumption • • Reference to the data sent first (originally) But situation is following • Short-term increase in the delay • • But not really any loss of data • • • New-Round_Trip_Sample: has very high values RTT increases Sender • Now, if sender detects (at later time) packets that have been lost • • • Acknowledgement arrives shortly after timeout Result • • For any unknown reason Retransmits at a (very) later point in time Consequently acknowledgements are also returned later Global effect • 24. Mar. 2004 RTT may increase even more and more 40 INF-3190: Transport Layer

RTT Calculation in Case of Error Recovery • • Situation: ambiguous measuring 2 nd assumption • • Reference to last retransmitted data But situation occurred due to • • Result • • • New_Round_Trip_Sample: has smaller value RTT is reduced Sender • • • Internet in fact losses data May set time interval which may be too short The acknowledgement of the first packages will again further reduce RTT Global effect • • RTT gets too small Usually at 1/2 of the actual value • 24. Mar. 2004 i. e. on the average each segment will be sent twice 41 INF-3190: Transport Layer

RTT Calculation in Case of Error Recovery • Fix: Karn’s algorithm • Ignore the measurements of lost packets • But this would not reflect actual system changes in a correct manner • Previous algorithm • Timer backoff strategy • • • Increase timeout for each lost packet (actually each segment) until a segment has arrived g-value: typically 2 Comment • • 24. Mar. 2004 By Phil Karn used TCP based on (very unreliable) radio transmission 42 INF-3190: Transport Layer

RTT Calculation in Case of Error Recovery • Further improvements • Karn’s algorithm • Bad adjustment whenever • • • High load means • • • Variation of consecutive delays is large e. g. short-long-short-long. . . Often large fluctuations within the delays Larger standard deviation (as well as average runtime deviation) Therefore deviation to be used (instead of b) • Previously • New algorithm 24. Mar. 2004 43 INF-3190: Transport Layer