Transport Protocols ISO Defined Types of Network Service

Transport Protocols

ISO Defined Types of Network Service: ! Type A: Network connection with acceptable residual error rate and acceptable rate of signaled failures. - Reliable, sequencing network service with arbitrary message size.

- Reliable, nonsequencing network service with arbitrary message size. - Reliable, nonsequencing network service with maximum message size. ! Type B: Network connections with acceptable residual error rate but unacceptable rate of signaled failures. ! Type C: Network connections with residual error rate not acceptable to the transport service user.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-1 Transport Layer Issues Reliable Sequencing Network Service ! Addressing: How to identify the target user. Typically, the user address is specified as (Host,Port) The Port represents a particular transport service user (e.g., TELNET,FTP,HTTP,SMTP,SNMP,RTP,..). The Host represents the attached network device (e.g., the global internet address) (In TCP, the combination of port and host is referred to as a socket. ! Multiplexing: Mapping transport connections onto network connections. ! Flow Control: Receiver Mechanisms: - Discard TPDUs that overflow the buffer. - Refuse to accept further TPDUs from the network., - Use a sliding window protocol. - Use a credit allocation mechanism. ! Connection Establishment and Termination: - Allows each end to assure that the other exists. - Allows negotiation of optional parameters. - Triggers allocation of transport entity resources.

Example of Credit Allocation Mechanism

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-7 Reliable Nonsequencing Network Service TPDUs may arrive out of order! ! Sequence numbers are required for connection oriented service. ! Credit allocations must be numbered sequentially. ! Data TPDUs may arrive before connection is fully opened. (Data TPDUs should be queued until connection is fully established.) ! TPDUs may arrive after a connection has been closed. (Solution is to have the connection termination message contain the number of the last data TPDU sent on this connection.)

Example: Flow Control with a Nonsequenced Network Service

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-9 Failure Prone Networks (Type B) ! The transport entity must cope with the problem of recovering from known loss of data and/or network connections. ! Note: the sequence numbering is an effective tool for dealing with network failures. Examples: ! X.25 Reset is Received: - Issue a control TPDU to the other end that acknowledges a reset condition and gives the number of the last data TPDU received. - Refrain from issuing new data TPDUs until a corresponding reset control TPDU is received from the other end. ! X.25 Restart is Received: - Issue a request to the network service for a new network connection. - Issue a control TPDU to the other end to identify the new network connection for the ongoing transport connection. - Resynchronize with the use of reset control TPDUs.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-10 Unreliable Network Service (Type C) A TPDU may fail to arrive at the destination and go undetected! ! Retransmission Strategy: - Must have a positive ACK scheme. - Must have a Retransmission Timer. ! Duplicate Detection: - Duplicate Received Prior to the Close of a Connection: a) The receiver must assume that its ACK was lost and send another ACK. b) The sequence number space must be long enough so as not to cycle in less than the maximum possible TPDU lifetime. - Duplicate Received After the Close of a Connection: a) Sequence numbers should extend across connection lifetimes (TCP). b) Provide a separate transport connection identifier and use a new identifier for each new connection. c) If a system crash occurs, the above two schemes can fail. One could use a Reconnection Timer to insure a minimum time between closing one connection and opening another with the same destination.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-12 ! Flow Control: - The credit allocation mechanism works well. - Add a Persist Timer to provide a maximum time between ACK/CREDIT TPDUs. ! Connection Establishment: - Since Connection Requests can get lost, retransmissions can cause delayed duplicates. - Must use a three-way-handshake to open connections. ! Connection Termination: - Each side must explicitly ACK each other's close message. - The close message must contain the sequence number of the last data TPDU sent. ! Crash Recovery: - Connections can become half-open. - Use a Keepalive Timer to abort nonresponsive connections.

! Network Layer Packets Used in the Example:

! Transmission Control Protocol (TCP) Connection-Oriented ! User Datagram Protocol (UDP) Connectionless

! TCP Services: - Provides reliable communications across reliable and unreliable networks and internets. - Stream oriented. - Data transport is: - Full Duplex - Timely - Ordered - Flow Controlled - Error Controlled - Supports security and precedence labeling. - Supports special capabilities: - Data Stream Push - Urgent Data Signaling - Designed specifically and exclusively to work with IP. ! UDP Services: - Provides a transport-level, unreliable, datagram service. - Delivery and duplicate detection are not guaranteed.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-25 TCP Service Request Primitives UNSPECIFIED-PASSIVE-OPEN: Listen for connection attempts at specified security and precedence levels from any remote user. FULL-PASSIVE-OPEN: Listen for connection attempts at specified security and precedence levels from specified user. ACTIVE-OPEN: Request connection at particular security and precedence levels.

ACTIVE-OPEN-WITH-DATA: Request connection at particular security and precedence levels and transmit data with request. SEND: Transfer data across named connection. ALLOCATE: Issue incremental allocation for receive data to TCP. CLOSE: Close connection gracefully. ABORT: Close connection abruptly. STATUS: Report connection status.

OPEN-ID (or OPEN_RECEIVED): Informs user of connection name assigned to pending connection requested in an OPEN primitive. OPEN-FAILURE: Reports failure of an ACTIVE-OPEN or request. OPEN-SUCCESS: Reports completion of an ACTIVE-OPEN request.

DELIVER: Reports arrival of data. CLOSING: Reports that remote TCP user has issued a CLOSE. TERMINATE: Reports that connections has been terminated and no longer exists. STATUS-RESPONSE: Reports current status of connection. ERROR: Reports service request or internal error.

TCP User Services - Time Sequence Diagram

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-28 TCP Service Request Primitives UNSPECIFIED-PASSIVE-OPEN (source-port, [timeout], [timeout- action], [precedence], [security]) FULL-PASSIVE-OPEN (source-port, destination-port, destination- address, [timeout], [timeout-action], [precedence], [security]) ACTIVE-OPEN (source-port, destination-port, destination-address, [timeout], [timeout-action], [precedence], [security]) ACTIVE-OPEN-WITH-DATA (source-port, destination-port, destination-address, [timeout], [timeout-action], [precedence], [security], data, data-length, push-flag, urgent-flag) SEND (local-connection-name, data, data-length, push-flag, urgent- flag, [timeout], [timeout-action]) ALLOCATE (local-connection-name, data-length) CLOSE (local-connection-name) ABORT (local-connection-name) STATUS (local-connection-name)

TCP Service Response Primitives OPEN-ID (local-connection-name, source-port, destination-port, destination-address) OPEN-FAILURE (local-connection-name) OPEN-SUCCESS (local-connection-name) DELIVER (local-connection-name, data, data-length, urgent-flag) CLOSING (local-connection-name) TERMINATE (local-connection-name, description) STATUS-RESPONSE (local-connection-name, source-port, source- address, destination-port, destination-address, connection- state, receive-window, send-window, amount-waiting-ack, amount-waiting-receipt, urgent-mode, timeout, timeout-action) ERROR (local-connection-name, description)

0 15 16 31

Source Port Destination Port

Sequence Number

Acknowledge Number

Data reserved Flags Window Offset

Checksum Urgent Pointer

Options and Padding

Data

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-31 TCP Header Parameters ! Source Port (16 bits): - Source SAP. ! Destination Port (16 bits): - Destination SAP. ! Sequence Number (32 bits): - Seq. Number of the first data octet in this TPDU. - When SYN is present, it is the initial sequence number (ISN) (first data octet is ISN+1). ! Acknowledgement Number (32 bits): - Next octet expected. ! Data Offset (4 bits): - Number of 32-bit words in header. ! Reserved (4 bits): (for future use) ! Flags: - CWR: Congestion window reduced flag Data sender notifies receiver that the sender’s congestion window has been reduced - ECE: ECN-Echo flag Data receiver notifies sender that IP packet with and ECN value of 11 (CE) has been received. - URG: Urgent pointer field significant - ACK: Acknowledgement field significant - PSH: Push function - RST: Reset the connection - SYN: Synchronize the sequence numbers - FIN: No more data from sender ! Window (16 bits): - Flow control credit allocation in octets. - Number of octets, beginning with the one specified in the ack field that the sender will accept. ! Checksum (16 bits): - 1's complement of the sum of all the 16-bit words. ! Urgent Pointer (16 bits): - Points to the octet following the urgent data.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-32 ! Options (variable): - Maximum segment size: Included within a SYN segment to indicate the maximum allowable incoming segment size. - Window scale: Included within a SYN segment. Ordinarily, credit allocation is in octets. When the window scale option is used, the value of the Window field is multiplied by 2F, where F is the value of the window scale option. - Sack-permitted: Indicates that selective acknowledgement is allowed. - Sack: Allows the receiver to inform the sender of all the segments that are received successfully. The sender will only retransmit segments that have not been received. - Timestamps: Allows the sending of a timestamp in a data segment and the return of an echo of that timestamp in a return ACK segment.

! Precedence parameter is mapped into the DS (Differentialed Services) field. ! Security parameter is mapped into the optional security field.

Connection Establishment: ! Always uses a Three-Way Handshake: - SYN - SYN + ACK - ACK Data Transfer: ! Viewed as a stream of octets. ! Each octet is numbered. ! Flow control using a credit allocation scheme (in octets (or the optionally set window scale)). ! TCP normally exercises its own discretion when to construct a TPDU - unless PUSH flag is used). ! RST flag when apparently incorrect data for current connection is received. (e.g. delayed duplicate SYN, acks for data not yet sent, etc.). Connection Termination: ! Graceful Close: - Transport user issues CLOSE primitive. - Transport entity sets the FIN bit on last TPDU sent. ! Abrupt Termination: - User issues an ABORT primitive. - Entity abandons all efforts to send or receive data. - Entity discards data in its buffers. - Entity sends out a RST TPDU.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-35 TCP Implementation Policy Options ! Send Policy: - In the absence of both pushed data and a closed transmission window, a sending TCP entity is free to transmit data at its own convenience, within its current credit allocation. - As data are issued by the user, they are buffered in the transmit buffer. - TCP may construct a segment for each batch of data provided by its user or it may wait until a certain amount of data accumulates before constructing and sending a segment. - The actual policy will depend on performance considerations. - If transmissions are infrequent and large, there is low overhead in terms of segment generation and processing. - If transmissions are frequent and small, the system is providing quick response. ! Deliver Policy: - In the absence of a Push, a receiving TCP entity is free to deliver data to the user at its own convenience. - It may deliver data as each in-order segment is received, or it may buffer data from a number of segments in the receive buffer before delivery. - The actual policy will depend on performance considerations. - If deliveries are infrequent and large, the user is not receiving data as promptly as may be desirable. - If deliveries are frequent and small, there may be unnecessary processing both in TCP and in the user software, as well as an unnecessary number of operating system interrupts.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-36 TCP Implementation Policy Options Cont. ! Accept Policy: - When all data segments arrive in order over a TCP connection, TCP places the data in a receive buffer for delivery to the user. - It is possible, however, for segments to arrive out of order. In this case, the receiving TCP entity has two options: • In-order: - Accept only segments that arrive in order; any segment that arrives out of order is discarded. - The in-order policy makes for a simple implementation but places a burden on the networking facility, as the sending TCP entity must retransmit segments that were successfully received but discarded because of misordering. - Furthermore, if a single segment is lost in transit, then all subsequent segments must be retransmitted once the sending TCP times out on the lost segment. • In-window: - Accept all segments that are within the receive window - Reduces transmissions but requires a more complex acceptance test and a more sophisticated data storage scheme to buffer and keep track of data accepted out of order.

! Retransmit Policy: - TCP maintains a queue of segments that have been sent but not yet acknowledged. - TCP will retransmit a segment if it fails to receive an acknowledgment within a given time. - A TCP implementation may employ one of three retransmission strategies: • First-only: - Maintain one retransmission timer for the entire queue. - If an acknowledgment is received, remove the appropriate segment or segments from the queue and reset the timer. - If the timer expires, retransmit the segment at the front of the queue and reset the timer. - The first-only policy is efficient in terms of traffic. - However, because the timer for the second segment in the queue is not set until the first segment is acknowledged, there can be considerable delays. • Batch: - Maintain one retransmission timer for the entire queue. - If an acknowledgment is received, remove the appropriate segment or segments from the queue and reset the timer. - If the timer expires, retransmit all segments in the queue and reset the timer. - The batch policy also reduces the likelihood of long delays but may result in unnecessary retransmissions. • Individual: - Maintain one timer for each segment in the queue. - If an acknowledgment is received, remove the appropriate segment or segments from the queue and destroy the corresponding timer or timers. - If any timer expires, retransmit the corresponding segment individually and reset its timer. - The individual policy solves the delay problem at the expense of a more complex implementation.

The actual effectiveness of the retransmit policy depends in part on the accept policy of the receiver.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-38 TCP Implementation Policy Options Cont. ! Acknowledge Policy: When a data segment arrives that is in sequence, the receiving TCP entity has two options concerning the timing of acknowledgment: • Immediate: When data are accepted, immediately transmit an empty (no data) segment containing the appropriate acknowledgment number. • Cumulative: When data are accepted, record the need for acknowledgment, but wait for an outbound segment with data on which to piggyback the acknowledgment. To avoid long delay, set a persist timer; if the timer expires before an acknowledgment is sent, transmit an empty segment containing the appropriate acknowledgment number. ! The immediate policy is simple and keeps the remote TCP entity fully informed, which limits unnecessary retransmissions. ! However, this policy results in extra segment transmissions, namely, empty segments used only to ACK. ! Because of the potential overhead of the immediate policy, the cumulative policy is typically used. ! Recognize that the use of this policy requires more processing at the receiving end and complicates the task of estimating round-trip time by the sending TCP entity.

! Basic Operation: - TCP host sending data sets ECT code (10 or 01) in IP header of every data segment sent. - If sender receives TCP segment with ECE set, sender adjusts congestion window as for fast recovery from single lost segment. - Next data segment sent has CWR flag set. This tells receiver that it has reacted to congestion - If router begins to experience congestion, may set CE code (11) in any packet with ECT code set. - When a receiver receives a packet with CE set it begins to set ECE flag on all acknowledgments (with or without data). - It continues to set ECE flag until it receives a segment with CWR set.

0 1516 31 Source Port Destination Port Length Checksum

Data

! UDP Uses: There are instances when the connection establishment and termination overhead is unjustified or even counterproductive: - Inward Data Collection: Involves periodic active or passive sampling of data sources; e.g., sensors, security equipment, network components, .... - Outward Data Dissemination: e.g., broadcast messages, distribution of real-time clock values, .... - Request-Response: Applications for which a single request-response is typical. The service is typically regulated at the application level and lower level connections are unnecessary and cumbersome. - Real-time Applications: e.g., real-time voice, video, and telemetry. These services must not have connection-oriened functions such as retransmission.

! TCP not suited to real time distributed application - Point-to-point not suitable for multicast - Retransmitted segments arrive out of order - No way to associate timing with segments

! UDP does not include timing information nor any support for real time applications

! Solution is real-time transport protocol RTP

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-50 RTP Fixed Header Format Fields ! Version: Current version is 2 ! Padding: Indicates whether padding octets appear at the end of the payload. If yes, last octet of payload has a count of the number of padding octets. ! Extension: If set, the fixed header is followed by exactly one extension header. ! CSRC Count: The number of CSRC identifiers that follow the fixed header. ! Marker: Interpretation is payload type dependent (e.g., for audio, if set, it marks the start of a talk spurt. ! Payload Type: Identifies the format of the RTP payload which follows the RTP header. ! Sequence Number: Sequential sequence number, of each RTP data packet sent. Allows for loss detection and packet sequencing within a series of packets with the same timestamp. ! Timestamp: corresponds to the generation instant of the first octet of the data payload. ! Synchronization Source Identifier: Randomly generated value to uniquely identify the source in a session. ! Contributing Source Identifier: Identifies a contributing source for the payload. (Supplied by a mixer).

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-52 RTP Control Protocol (RTCP) A separate control protocol (RTCP) provides feedback to RTP data sources as well as all session participants. RTCP uses the same underlying transport service as RTP (usually UDP) and a separate port number. Each participant periodically issues an RTCP packet to all other session members. RTCP functions: • Quality of Service (QoS) and congestion control: - RTCP provides feedback on the quality of data distribution. - Because RTCP packets are multicast, all session members can assess how well other members are performing and receiving. - Sender reports enable receivers to estimate data rates and the quality of the transmission. - Receiver reports indicate any problems encountered by receivers, including missing packets and excessive jitter. • Identification: - RTCP packets carry a persistent textual description of the RTCP source. - This provides more information about the source of data packets than the random SSRC identifier and enables a user to associate multiple streams from different sessions. • Session size estimation and scaling: - The rate of transmission of RTCP packets must be scaled down (to <5% traffic) as the number of participants increases. • Session control: - RTCP optionally provides minimal session control info. An example is a participant identification to be displayed in the user interface.

! RTCP sender and receiver reports provide transmission of QoS information between senders and receivers. ! Sender reports include information for synchronizing media streams, expected data rate, expected packet rate, and distance in time from the receiver to the sender. ! Receiver reports include fraction of lost packets, cumulative lost packets, last sequence number received, and interarrival jitter.

! Interarrival jitter provides a short term measure of network congestion. ! Packet loss tracks persistent congestion while jitter tracks transient congestion.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-57 SR & RR Header and SR Sender Report Fields ! Version: ! Padding: ! Report Count: Number of reception report blocks contained in the packet. ! Packet Type: ! Length: length of this packet in 32 bit words, minus 1. ! NTP Timestamp: The absolute wall clock time when this report was generated. Used in combination with timestamps returned in reception reports from other receivers to measure round-trip propagation to those receivers. ! RTP Timestamp: This is the relative time used to create timestamps in RTP data packets. ! Sender's Packet Count: Total number of RTP data packets transmitted so far by the sender in this session. ! Sender's Octet Count: Total number of RTP payload octets transmitter so far by this sender in this session.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-58 SR & RR: Reception Report Fields ! SSRC_n: Identifies the source referred to by this report. ! Fraction Lost: The fraction of RTP data packets from SSRC_n lost since the previous SR or RR packet was sent. ! Cumulative Number of Packets Lost: Total number of RTP data packets lost from SSRC_n during this session. ! Extended Highest Sequence Number Received: The least significant 16 bits record the highest sequence number received from the SSRC_n. The most significant 16 bits record the number of times the sequence number has wrapped back to zero. ! Interarrival Jitter: An estimate of the jitter experienced on RTP data packets from SSRC_n. ! Last SR Timestamp: the middle 32 bits of the NTP timestamp in the last SR packet received from SSRC_n. ! Delay Since last SR: The delay, in units of 2-16 seconds between receipt of the last SR packet from SSRC_n and the transmission of this report block.

! Used by a source to provide information about itself. ! The packet has a 32-bit header followed by zero or more fields of information about this source. ! Each field begins with an identifier for this source or for a contributing source, followed by a list of descriptive items.

Copyright © September 13, 2009 by Chaim Ziegler, Ph.D. Transport-61 The RTCP Goodbye (BYE) Packet ! The BYE packet indicates that one or more sources are no longer active. ! The packet consists of a 32-bit header followed by one or more source identifiers.