Internet Engineering Task Force Vijay Madisetti, Antonios Argyriou INTERNET-DRAFT Georgia Institute of Technology July 25, 2002 A Transport Layer Technology for Improving QoS of Networked Multimedia Applications Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Voice & Video over Internet have strict QoS requirements. Generally, low jitter, low delay and high bandwidth are the critical requirements for this class of applications. However, achieving this goal is difficult, more so in a wireless/internet environment, where the both networking & communication channel conditions are dynamically changing over time. In this document, we propose a novel transport layer protocol that attempts to provide better QoS for multimedia applications. The purpose of the proposed technology is to act additively to existing QoS solutions at the lower protocol layers through enhancements to the SCTP protocol. Contents 1 Introduction ...................................................2 2 Relevant SCTP Functionality ....................................2 2.1 Multi-homing ..............................................2 2.2 Multi-streaming ...........................................3 2.3 Partially Reliability SCTP Extension ......................3 3 QoS aware protocol .............................................3 3.1 Monitoring Path Quality ...................................4 3.2 Stream per path assignment ................................5 3.3 Sending Data ..............................................6 Madisetti, Argyriou. [Page 1] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 3.4 Example: Transmitting scalable encoded video ..............7 4 UMTS Application classes .......................................7 5 API extensions .................................................8 6 Advantages .....................................................9 7 Intellectual Property Statement ................................9 8 Authors' Addresses ............................................10 1 Introduction The proposed technology provides a number of new types of services to application layer protocols and also stand-alone applications. We believe that by integrating intelligent functionality at the transport layer, we can leverage the existing gap between the needs of novel application layer protocols and the old transport layer technology (i.e., TCP). The proposed scheme consists of a number of extensions to the base SCTP [1] protocol that do not compromise its basic functionality. The proposed extensions use a framework that consists of a number application classes that can capture various application layer protocol data formats and data exchange demands. In other words, we distinguish the way data is sent at the transport layer according to the class the data is assigned to by the user. The classes of data types that we are using are the ones proposed at Universal Mobile Telephone System (UMTS) [2]: conversational class, streaming class, interactive class, and background class. Adopting the application classes as the above is not restrictive for any kind of application layer protocol but instead provides the right abstraction for manipulating data at the modified SCTP layer. Purpose of the above mentioned classification is to treat data transfer, at a later stage, differently according to high-level demands and QoS requirements. By specifying data transfer more precisely (i.e., signalling info, layered video, etc.) we would restrict the applicability of the protocol into a wider class of applications. So, by selecting the proposed data transfer methods, SCTP could treat the data according to the class they belong and the rules that we have specified. Voice, video, and interactive multimedia applications can exploit the advanced features offered by the new extended SCTP protocol. Examples of such applications are provided in later sections. 2 Relevant SCTP Functionality In this section we analyze SCTP functionality that is closely related to the specific features of the protocol that we are proposing. 2.1 Multi-homing SCTP introduces the idea of multi-homed hosts, where an endpoint that belongs to a single association (connection between two endpoints) can have more than one addresses from which it is reachable at the transport Madisetti, Argyriou. [Page 2] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 layer. Moreover, both the endpoints can use interchangeably these transport addresses as source and destination addresses, without disrupting an ongoing session [3]. Primary goal of adding multihoming to SCTP was to improve fault tolerance t the transport layer [1]. However, having a number of different IP addresses does not necessary guarantee different physical paths between two communication endpoints even if it is highly probable. But the idea of multi-homing and the possibility of existing multiple paths is very important for the proposed protocol. 2.2 Multi-streaming Another interesting feature is that SCTP is a stream-based protocol. This means that user messages that belong to the same stream are delivered in order to the ULP while user messages of different streams can be delivered out of order. In this way, the use of streams, prevents Head Of Line blocking [1] and can speed up the delivery of user messages. The existence of streams at the base SCTP protocol is another useful feature for our protocol: It uses SCTP streams as a lightweight mechanism for distinguishing application level data streams and mapping them to SCTP streams. This means that an application layer data "stream" is mapped to an SCTP stream. 2.3 Partially Reliable SCTP Extension A recently proposed extension to the base SCTP protocol, that provides partially reliable data delivery can be found in [4]. The proposed way of providing partially reliable services is accomplished mainly by use of a new SCTP chunk type called Forward TSN [4]. This type of chunk is sent by a data sender when it wants to advance the receiver's Cumulative TSN Ack Point [1]. In other words, it forces the receiver to consider all the chunks with sequence number smaller than the one sent in this chunk as already received. Moreover, this kind of partially reliable services can be applied in a number of streams that consist an association. In this way data streams that require no acknowledgment can be created and operate like a separate unreliable transport level service. We also suggest that a Forward TSN chunk COULD be sent from a client also. In this way the receiver decides whether he has received the required amount of data. The user/receiver can thus tradeoff quality against performance. 3 QoS-aware protocol In this section we will go over the the basic steps of this proposal, in order to provide a complete overview of its functionality. The proposed, new protocol operates at the transport layer, and we also assume the use of SCTP [1] as the underlying transport layer protocol. Moreover, the use of the partially reliable extension, found in [4] is assumed. Madisetti, Argyriou. [Page 3] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 We believe that providing QoS to flows at the transport layer may provide significant enhancement in the final QoS delivered to an application. Interactive multimedia applications have very stringent QoS requirements, and that is why we should try to provide QoS at each layer of the protocol stack. One of the basic ideas of this proposal is that it makes use of a number of active alternative paths (that are created by routers) at the transport layer. The proposal assigns each application flow to the "best" path according to predefined QoS criteria. The proposed protocol also classifies different data flows of an application, according to the application classes found in [2]. The user has the flexibility of mapping data flows to SCTP streams so that it will allow easier handling from the base protocol. The notion of SCTP streams provides the additional flexibility for an application to distinguish the messages sent in different paths. Moreover, an SCTP stream is independent from other streams in the sense that blocking occurs only per stream and does not affect all the other streams [1]. The proposed protocol consists the following four steps: 1) The protocol probes the multiple existing paths between two communicating hosts and tries to determine their "quality" according to well specified metrics. These are: delay, latency (RTT), bandwidth, jitter, packet loss rate. This path probing step should be performed when it is actually needed since we do not want to flood the network with excessive traffic. In the next subsection we provide detailed information about this part of the protocol. 2) The protocol reconfigures on the fly the stream per path assignment of an existing SCTP association. The mapping mechanism of SCTP streams to paths is dynamic. Each path has its own "state" which is updated according to statistics collected from step (1). 3) Assignment of user flows to specific streams of an association. The user can usually assign each of the application flows to SCTP streams. He MUST also be allowed to specify explicitly the address of the other endpoint for a specific flow/stream. For example a user could dictate the that signalling messages are sent to the most reliable path, while the bulk data (i.e. video) to the one with the most available bandwidth. 4) Providing and API that can capture user/application QoS requirements and data transfer needs. In a previous section we described how the new data transfer services can be captured by the enhanced API and finally mapped to SCTP functionality. 5) The protocol also modifies the SCTP functionality related to HEARTBEAT [1] messages. The protocol controls in the number and exact moment in time the HEARTBEATs are sent, and also the number and time of FWD_TSN chunks [4] sent. In the next sections we are going to explain in detail each of the protocol steps, and analyze their interaction. 3.1 Monitoring Path Quality In order to be able to make decisions concerning the "quality" of a path, we must find a way to gather information about it. One important Madisetti, Argyriou. [Page 4] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 consideration here, is to not flood the network with excessive traffic that it will reduce the available bandwidth. That is why we must try to extract information about each network paths status from existing information available from the base SCTP protocol. The metrics that we are considering are: A)Delay: A new variable _path_delay_will be retained for each of the active paths in an association. This delay can be extracted from the incoming SCTP HEARTBEAT messages timestamp. By using this information we do not have to send any other kind of messages that are destined only for this purpose. B)Latency: Latency is usually measured by the use Round Trip Time (RTT). RTT is already maintained for each one of the transport addresses of an SCTP association. By using RTT we can measure the responsiveness of a specific path can be examined and stored for further usage. Additionally SRTT (Smoothed RTT) could be used in order to obtain more reliable statistics about a path. C)Bandwidth: Measuring and maintaining information about the bandwidth of a specific path, is very useful. An example of a flow that would be primarily concerned about the bandwidth is video on demand. In this case we do not care about the latency of a path but only about its throughput. A new variable _path_bandwidth_ is maintained per each transport address and is updated from the protocol dynamically. D)Jitter: Variation in delay should is of primary importance for Voice over IP applications. This class of applications requires very low jitter. A variable _path_jitter is also maintained for each transport address. Defining _path_jitter_is up to the implementation and as the average variation of delay of a fixed number of delay measurements for each path. E)Packet loss rate: Increased packet loss rate for a channel, means that it is not reliable enough. Signalling network traffic (i.e. SIP) needs a highly reliable service since inability to transfer signalling info correctly initially could prevent us sending actual data. The _loss_rate_variable is used for keeping the packet loss rate for each path. 3.2 Stream per path assignment Assigning intelligently user defined stream(s) to different paths is one of the major functions that the proposed protocol. The basic problem with SCTP is that it cannot guarantee that by having multiple transport addresses about our peer, each of these addresses will correspond to a different physical path. This is primary concern of the core network components such as routers. The proposed protocol acts additively to existing lower layer solutions. In one of our previous drafts [5] we proposed a way of maintaining addresses for mobile hosts Madisetti, Argyriou. [Page 5] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 that correspond to different physical paths. And in one of our new drafts [7] we propose a method to create and maintain non-overlapping paths by the use of SCTP and MPLS. Initially, the remote endpoint addresses are configured by the user i.e. the user is the one that determines the address(es) of the endpoint that he wants to connect to. Having knowledge of the available paths between the two endpoints, and their corresponding "quality", according to the previous collected network statistics (see previous section) , the protocol labels each one of the paths. Each stream in an SCTP association MUST be mapped to one these paths. This means that all the data from this stream will be sent though this specific path. Additionally each stream will have to maintain a _label_that indicates its current REQUIRED Quality of Service. A _label_exists for each one of the monitored metrics mentioned in the previous section. The QoS protocol examines the state of each path periodically. Its purpose will be to make sure that at all times, the stream that requires the best available service (in terms of the previously defined metrics) corresponds to a path that satisfies as much as possible these requirements. In the case where multiple user streams require the same kind of service quality (e.g. low delay) scheduling must be performed. We are currently using RR scheduling that reassigns a high quality path into two different flows with the same requirements. However, it is up to the user to specify the required treatment that each flow must have. For example, if we have two flows that send data with completely different rate, the user can request that they enjoy the same treatment. The following section provides a detailed explanation of the protocol internal operation. 3.3 Sending Data The enhanced SCTP, has another degree of intelligence incorporated on it : It intelligently decides when it should drop some redundant user data ( not actually commit to the network layer) due to network congestion. However, in order for SCTP to be able to perform this "dropping" it must know which information is the "base" that must be delivered in any way and which information can be dropped under network congestion or increased loss conditions (i.e. in wireless nodes). This is achieved by assigning a _label_at each data stream that the application feeds to the SCTP layer. These _label(s)_MUST be in the form _base_obj, _enh_obj_1, enh_obj_2,. The following pseudo code depicts this part of the protocol. for(i=1;i<=NUM_TRANSPORT_ADDRESSES) { if(cwnd_transport_add(i)<=_base_obj) { send[dest(i)]; Madisetti, Argyriou. [Page 6] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 goto send_more; } else { fragment data or use Load Balancing SCTP } send_more: if(cwnd_transport_add(i)<=_enh_obj(i)) { send[dest(i)]; goto send_more; } else continue; } In this way we avoid the problem initially. We do not inject excessive network traffic and then use a packet dropping mechnism (i.e. priority dropping) at a router to drop the packets due to congestion. The enhanced SCTP will decide according to the observed network traffic if and when to inject the supplementary information. 3.4 Example: Transmitting scalable encoded video A Scalable video codec produces a base layer (BL) and several enhancement layers (EL) which can enhance the base layer description quality. Since the BL is the most important description it is protected better using FEC. The modified SCTP handles differently each encoded layer. Thebase layer is assigned to a stream which corresponds to a highly reliable path (_base_obj). and assigns all the other Enhancement Layers (EL) to other streams (_enh_obj_x). Streams can also carry just (Forward Error Correction) FEC information in the case of video transmission. In this way we are trying to make sure that the base information gets to the client and if the network allows it, it can also receive the additional enhancement/correcting information. Moreover if the other extension that we propose [8] is used in order to achieve load-balancing and not just satisfy some QoS requirements, the enhanced SCTP MAY decide to use low bandwidth links for sending ELs. 4 UMTS Application classes The most important feature of UMTS [2] is the possibility of guaranteeing a particular QoS for different applications or user groups. With this kind of QoS, someone can hold video conferences which are not suffering from jitter. Moreover, different service classes for business and private users will be introduced. In the business sector, Quality of Service mechanisms are very important for the success for UMTS. To offer Quality of Service, Madisetti, Argyriou. [Page 7] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 UMTS employs four classes of traffic which are suited to requests for different types of data transfer. The lowest level is the Background Class. For this class, neither constant bit rates nor high transfer speeds are essential; the information only need be uncorrupted when it arrives. This class is suited for information transfers that are to be worked with once they are completely acknowledged as received. Examples include fax documents or e-mail messages. To the next level, one reaches the Interactive Class. In this class, constant bit rates are also not required. However, demands for speed are higher, as is the guarantee of error-free data transfers. A web browser is an application that requires this level of service quality, as the faster display of screen information is certainly desired, but short delays in the transfer present no problems. The Streaming Class is a step higher. Here, above all, constant data transfer rates are important. As the name indicates, this class is suitable for transferring audio and video streams. As such, brief disruptions in transfer rates are noticeable, resulting in jittering pictures or stuttering during sound playback. Finally, there is the Conversational Class. The emphasis here lies, above all, on real-time transfers and temporal fluctuations. For this reason, one can put up with minor errors during transfer. Next to the classic example of voice communications, video telephony is an application which makes use of this quality of service. 5 API extensions The new data transfer options that correspond to each of the application classes, must be exposed to the application layer in a simple and concrete fashion. According to the socket extension draft [6] all the SCTP-specific socket extensions MUST use the ancillary data format to specify and access data via the struct msghdr's msg_control member used in sendmsg() and recvmsg(). We defined a new option SCTP_QOSMSG which is used by the sendmsg() only. cmsg_level cmsg_type cmsg_data[] ------------ ------------ ---------------------- IPPROTO_SCTP SCTP_QOS struct sctp_qosmsg Here is the definition of the sctp_qosmsg structure: struct sctp_qosmsg { uint16_t sctp_base_obj; Madisetti, Argyriou. [Page 8] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 uint16_t sctp_enh_obj[MAX_STREAMS]; uint8_t use_prsctp; }; sctp_base_obj: 16 bits (unsigned integer) This is an integer that represents the Stream ID (SID) of the stream that will carry the base information. This is the part of the total data-stream that is the most important and must be delivered. sctp_enh_obj: 16 bits (unsigned integer) This is an array of integers that represents the Stream IDs (SID) of the streams that will carry the enhancement information. The enhanced SCTP will decide if it will use the user data that will be supplied in this stream. sctp_use_prsctp: 16 bits (unsigned integer) This is just a flag that indicates whether user wants the PRSCTP mode to be activated or not. 6 Advantages 1) The proposed extension is both sender and receiver based. Both the receiver and the sender of the flow may have the ability to modify parameters of an existing association on the fly in order to reflect network dynamics. 2)We aggregate user flows that correspond to a single connection to the same association. Since congestion control for SCTP is performed per association basis, reforming of the user flows (streams) can be done in order to match congestion control parameters. In this favor we could favor some flows that we want without affecting the congestion window. 3)It is a scalable solution since we do no not require any kind of modification or state maintenance from network components, such as routers. Path and stream state is kept in each communication endpoint. 4) The adoption of the application classes found in UMTS can help the adoption of the modified SCTP protocol for 3G wireless devices. UMTS can handle application classes on its own way, but with SCTP we add another degree of QoS, error-resilience, load-balancing at the transport layer. 7 Intellectual Property Statement Georgia Tech may have patent rights on technology described in this document which employees of Georgia Tech contribute for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, Georgia Tech hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any Madisetti, Argyriou. [Page 9] INTERNET-DRAFT A Transport Layer QoS Protocol July 2002 patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. 8 Authors' Addresses Vijay K. Madisetti School of Electrical & Computer Engineering Georgia Institute of Technology 30332 Atlanta GA, USA e-mail: vijay.madisetti@ece.gatech.edu Antonios D. Argyriou School of Electrical & Computer Engineering Georgia Institute of Technology 30332 Atlanta GA, USA e-mail: anargyr@ece.gatech.edu References [1]R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream Control Transmission Protocol ", RFC 2960, October 2000. [2]http://www.umts-forum.org/ [3]R. R. Stewart, Q. Xie, M. Tuexen, I. Rytina, "SCTP Dynamic Addition of IP Addresses", , January 2002. [4]R. Stewart, M. Ramalho et al., "SCTP Partial Reliability Extension", , May 2002. [5]V. Madisetti, A. Argyriou, "Voice & Video over Mobile IP Networs", , May 20, 2002. [6]R. R. Stewart, et. al, "Sockets API Extensions for Stream Control Transmission Protocol", , May 12, 2002. [7]V. Madisetti, A. Argyriou, "An protocol for MPLS performance enhancement", , July 25, 2002. [8]V. Madisetti, A. Argyriou, "A Transport Layer Load-Balancing Mechanism", , July 25, 2002. Madisetti, Argyriou. [Page 10]