transport protocols iso defined types of network service

Transport-1Copyright © September 13, 2009 by Chaim Ziegler, Ph.D.

Transport Protocols

ISO Defined Types of Network Service:

! Type A:

Network connection with acceptable residual errorrate and acceptable rate of signaled failures.

- Reliable, sequencing network service witharbitrary message size.

- Reliable, nonsequencing network service witharbitrary message size.

- Reliable, nonsequencing network service withmaximum message size.

! Type B:

Network connections with acceptable residual errorrate but unacceptable rate of signaled failures.

! Type C:

Network connections with residual error rate notacceptable to the transport service user.


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 serviceuser (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 referredto as a socket.

! Multiplexing:Mapping transport connections onto networkconnections.

! 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

Credit Allocation Mechanism


TCP Credit Allocation Mechanism


Sending & Receiving Flow Control Perpsectives


Simple Connection State Diagram: 2-way Handshake


Connection Establishment Scenarios


Example: Flow Control with a Nonsequenced Network Service

Reliable Nonsequencing Network Service

TPDUs may arrive out of order!

! Sequence numbers are required for connection orientedservice.

! Credit allocations must be numbered sequentially.! Data TPDUs may arrive before connection is fully

opened. (Data TPDUs should be queued untilconnection is fully established.)

! TPDUs may arrive after a connection has been closed.(Solution is to have the connection terminationmessage contain the number of the last data TPDUsent on this connection.)


Reliable Nonsequencing Network Servicewith Maximum TPDU Size

! Fragmentation and reassembly required at the transportlayer.


Failure Prone Networks (Type B)

! The transport entity must cope with the problem ofrecovering from known loss of data and/or networkconnections.

! Note: the sequence numbering is an effective tool fordealing with network failures.

Examples:

! X.25 Reset is Received:

- Issue a control TPDU to the other end thatacknowledges a reset condition and gives thenumber of the last data TPDU received.

- Refrain from issuing new data TPDUs until acorresponding reset control TPDU is receivedfrom the other end.

! X.25 Restart is Received:

- Issue a request to the network service for a newnetwork connection.

- Issue a control TPDU to the other end to identifythe new network connection for the ongoingtransport connection.

- Resynchronize with the use of reset control TPDUs.


Unreliable Network Service (Type C)

A TPDU may fail to arrive at the destination and goundetected!

! 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 themaximum 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 eachnew connection.

c) If a system crash occurs, the above twoschemes can fail. One could use aReconnection Timer to insure a minimumtime between closing one connection andopening another with the same destination.


Example of TCP Incorrect Duplicate Detection(Assume Sequence Space = 1600)


! 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.


2-way handshake: Problem with Obsolete Data


2-way handshake: Problem with Obsolete SYN


TCP Entity State Diagram (Three-Way Handshake)


Examples of a Three-Way Handshake


Example: A Simple Transport Protocol

! Primitives for a Simple Transport Service:

! Network Layer Packets Used in the Example:


State Diagram for Transport Protocol Example


Finite State Machine Representation


A Simple Transport Protocol


A Simple Transport Protocol cont.


Transport Protocols

! 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 withIP.

! UDP Services:- Provides a transport-level, unreliable, datagram

service.- Delivery and duplicate detection are not

guaranteed.


TCP Service Request Primitives

UNSPECIFIED-PASSIVE-OPEN:Listen for connection attempts at specified securityand precedence levels from any remote user.

FULL-PASSIVE-OPEN:Listen for connection attempts at specified securityand precedence levels from specified user.

ACTIVE-OPEN:Request connection at particular security andprecedence levels.

ACTIVE-OPEN-WITH-DATA:Request connection at particular security andprecedence 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.


TCP Service Response Primitives

OPEN-ID (or OPEN_RECEIVED):Informs user of connection name assigned to pendingconnection 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 nolonger exists.

STATUS-RESPONSE:Reports current status of connection.

ERROR:Reports service request or internal error.


TCP User Services - Time Sequence Diagram

TCP User Services - Time Sequence Diagram


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)


Use of TCP and IP Service Primitives


TCP TPDU Format

0 15 16 31

Source Port Destination Port

Sequence Number

Acknowledge Number

DataOffset

reserved Flags Window

Checksum Urgent Pointer

Options and Padding

Data


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 flagData sender notifies receiver that the sender’scongestion window has been reduced

- ECE: ECN-Echo flagData receiver notifies sender that IP packet withand 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.


! Options (variable):- Maximum segment size:

Included within a SYN segment to indicate themaximum allowable incoming segment size.

- Window scale: Included within a SYN segment. Ordinarily, creditallocation is in octets. When the window scaleoption is used, the value of the Window field ismultiplied by 2 , where F is the value of theF

window scale option.- Sack-permitted:

Indicates that selective acknowledgement isallowed.

- Sack:Allows the receiver to inform the sender of allthe segments that are received successfully. Thesender will only retransmit segments that havenot been received.

- Timestamps:Allows the sending of a timestamp in a datasegment and the return of an echo of thattimestamp in a return ACK segment.


Parameters passed to IP:

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

! Security parameter is mapped into the optionalsecurity field.


TCP Mechanisms

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 duplicateSYN, 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.


TCP Implementation Policy Options

! Send Policy:- In the absence of both pushed data and a closed

transmission window, a sending TCP entity isfree to transmit data at its own convenience,within its current credit allocation.

- As data are issued by the user, they are buffered inthe transmit buffer.

- TCP may construct a segment for each batch ofdata provided by its user or it may wait until acertain amount of data accumulates beforeconstructing and sending a segment.

- The actual policy will depend on performanceconsiderations.

- If transmissions are infrequent and large, there islow overhead in terms of segment generation andprocessing.

- If transmissions are frequent and small, the systemis 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 ownconvenience.

- It may deliver data as each in-order segment isreceived, or it may buffer data from a number ofsegments in the receive buffer before delivery.

- The actual policy will depend on performanceconsiderations.

- If deliveries are infrequent and large, the user is notreceiving data as promptly as may be desirable.

- If deliveries are frequent and small, there may beunnecessary processing both in TCP and in theuser software, as well as an unnecessary numberof operating system interrupts.


TCP Implementation Policy Options Cont.

! Accept Policy:- When all data segments arrive in order over a TCP

connection, TCP places the data in a receivebuffer for delivery to the user.

- It is possible, however, for segments to arrive outof order. In this case, the receiving TCP entityhas two options:• In-order: - Accept only segments that arrive in order; any

segment that arrives out of order isdiscarded.

- The in-order policy makes for a simpleimplementation but places a burden on thenetworking facility, as the sending TCPentity must retransmit segments that weresuccessfully received but discarded becauseof misordering.

- Furthermore, if a single segment is lost intransit, then all subsequent segments mustbe retransmitted once the sending TCP timesout 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 moresophisticated data storage scheme to bufferand keep track of data accepted out oforder.



! 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 thetimer.

- If the timer expires, retransmit the segment at the frontof 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 isacknowledged, 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 thetimer.

- If the timer expires, retransmit all segments in the queueand reset the timer.

- The batch policy also reduces the likelihood of longdelays 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 thecorresponding timer or timers.

- If any timer expires, retransmit the correspondingsegment individually and reset its timer.

- The individual policy solves the delay problem at theexpense of a more complex implementation.

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



! Acknowledge Policy:When a data segment arrives that is in sequence, thereceiving TCP entity has two options concerning thetiming of acknowledgment:• Immediate:

When data are accepted, immediately transmit anempty (no data) segment containing theappropriate acknowledgment number.

• Cumulative: When data are accepted, record the need foracknowledgment, but wait for an outboundsegment with data on which to piggyback theacknowledgment. To avoid long delay, set a persist timer; if thetimer expires before an acknowledgment is sent,transmit an empty segment containing theappropriate acknowledgment number.

! The immediate policy is simple and keeps the remoteTCP entity fully informed, which limits unnecessaryretransmissions.

! However, this policy results in extra segmenttransmissions, namely, empty segments used only toACK.

! Because of the potential overhead of the immediatepolicy, the cumulative policy is typically used.

! Recognize that the use of this policy requires moreprocessing at the receiving end and complicates thetask of estimating round-trip time by the sending TCPentity.


Basic Explicit Congestion Notification (ECN) Operation

! 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 fastrecovery from single lost segment.

- Next data segment sent has CWR flag set. This tellsreceiver that it has reacted to congestion

- If router begins to experience congestion, may setCE code (11) in any packet with ECT code set.

- When a receiver receives a packet with CE set itbegins to set ECE flag on all acknowledgments(with or without data).

- It continues to set ECE flag until it receives asegment with CWR set.


The TCP Entity State Diagram


Example of TCP Operation


Example of TCP Operation cont.


Currently Assigned TCP Port Numbers


UDP TPDU Format

0 1516 31

Source Port Destination Port

Length Checksum

Data

! UDP Uses:

There are instances when the connection establishment andtermination overhead is unjustified or evencounterproductive:

- Inward Data Collection:Involves periodic active or passive sampling of datasources; e.g., sensors, security equipment, networkcomponents, ....

- Outward Data Dissemination:e.g., broadcast messages, distribution of real-timeclock values, ....

- Request-Response:Applications for which a single request-response istypical. The service is typically regulated at theapplication level and lower level connections areunnecessary and cumbersome.

- Real-time Applications:e.g., real-time voice, video, and telemetry. Theseservices must not have connection-oriened functionssuch as retransmission.


Currently Assigned UDP Port Numbers


Real Time Transport Protocol (RTP)

! TCP not suited to real time distributedapplication- 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 norany support for real time applications

! Solution is real-time transport protocol RTP


RTP Protocol Architecture


RTP Header


RTP Fixed Header Format Fields

! Version: Current version is 2

! Padding: Indicates whether padding octets appear at theend of the payload. If yes, last octet of payload has acount of the number of padding octets.

! Extension: If set, the fixed header is followed by exactly oneextension header.

! CSRC Count: The number of CSRC identifiers that followthe fixed header.

! Marker: Interpretation is payload type dependent (e.g., foraudio, if set, it marks the start of a talk spurt.

! Payload Type: Identifies the format of the RTP payloadwhich follows the RTP header.

! Sequence Number: Sequential sequence number, of eachRTP data packet sent. Allows for loss detection andpacket sequencing within a series of packets with thesame timestamp.

! Timestamp: corresponds to the generation instant of thefirst octet of the data payload.

! Synchronization Source Identifier: Randomly generatedvalue to uniquely identify the source in a session.

! Contributing Source Identifier: Identifies a contributingsource for the payload. (Supplied by a mixer).


Payload Types for Audio and Video Encodings


RTP Control Protocol (RTCP)

A separate control protocol (RTCP) provides feedback to RTPdata 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 othersession members.

RTCP functions:• Quality of Service (QoS) and congestion control:

- RTCP provides feedback on the quality of datadistribution.

- Because RTCP packets are multicast, all sessionmembers can assess how well other members areperforming and receiving.

- Sender reports enable receivers to estimate data ratesand the quality of the transmission.

- Receiver reports indicate any problems encountered byreceivers, including missing packets and excessivejitter.

• 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 enablesa user to associate multiple streams from differentsessions.

• Session size estimation and scaling: - The rate of transmission of RTCP packets must be

scaled down (to <5% traffic) as the number ofparticipants increases.

• Session control: - RTCP optionally provides minimal session control info.

An example is a participant identification to bedisplayed in the user interface.


RTCP Packet Formats


RTP Control Protocol (RTCP)

! The primary function of RTCP is to provide feedback on thequality of the data distribution.

! RTCP sender and receiver reports provide transmission ofQoS information between senders and receivers.

! Sender reports include information for synchronizing mediastreams, expected data rate, expected packet rate, anddistance in time from the receiver to the sender.

! Receiver reports include fraction of lost packets, cumulativelost packets, last sequence number received, andinterarrival jitter.


The RTCP Sender Report (SR) Packet


The RTCP Receiver Report (RR) Packet

! Interarrival jitter provides a short term measure of networkcongestion.

! Packet loss tracks persistent congestion while jitter trackstransient congestion.


SR & RR Header and SR Sender Report Fields

! Version:

! Padding:

! Report Count: Number of reception report blocks containedin the packet.

! Packet Type:

! Length: length of this packet in 32 bit words, minus 1.

! NTP Timestamp: The absolute wall clock time when thisreport was generated. Used in combination withtimestamps returned in reception reports from otherreceivers to measure round-trip propagation to thosereceivers.

! RTP Timestamp: This is the relative time used to createtimestamps in RTP data packets.

! Sender's Packet Count: Total number of RTP data packetstransmitted so far by the sender in this session.

! Sender's Octet Count: Total number of RTP payload octetstransmitter so far by this sender in this session.


SR & RR: Reception Report Fields

! SSRC_n: Identifies the source referred to by this report.

! Fraction Lost: The fraction of RTP data packets fromSSRC_n lost since the previous SR or RR packet was sent.

! Cumulative Number of Packets Lost: Total number of RTPdata packets lost from SSRC_n during this session.

! Extended Highest Sequence Number Received: The leastsignificant 16 bits record the highest sequence numberreceived from the SSRC_n. The most significant 16 bitsrecord the number of times the sequence number haswrapped back to zero.

! Interarrival Jitter: An estimate of the jitter experienced onRTP data packets from SSRC_n.

! Last SR Timestamp: the middle 32 bits of the NTPtimestamp in the last SR packet received from SSRC_n.

! Delay Since last SR: The delay, in units of 2 seconds-16

between receipt of the last SR packet from SSRC_n andthe transmission of this report block.


The RTCP Source Description (SDES) Packet

! Used by a source to provide information about itself.

! The packet has a 32-bit header followed by zero or morefields of information about this source.

! Each field begins with an identifier for this source or for acontributing source, followed by a list of descriptiveitems.


SDES Types


The RTCP Goodbye (BYE) Packet

! The BYE packet indicates that one or more sources are nolonger active.

! The packet consists of a 32-bit header followed by one ormore source identifiers.

transport protocols iso defined types of network service

Documents