A Transparent QoS Mechanism to Support IntServ/DiffServ Networks

Transcription

1 A Transparent QoS Mechanism to Support IntServ/DiffServ Networks Chi-Huang Shih, Chung-Chih Liao, Ce-Kuen Shieh, Wen-Shyang Huang* Department of Electrical Engineering, National Cheng Kung University, Taiwan *Department of Electrical Engineering, National Kaohsiung University of Applied Science, Taiwan Abstract IntServ and DiffServ networks are both proposed to promote the Quality of Service (QoS) for multimedia applications in the Internet. However, the complexity of communication between diverse applications and underlying QoS architectures leads one of the deployment problems, which decreases the utility of QoS provisioning. Without modifying legacy applications, this paper presents a transparent QoS mechanism (TQM) to communicate with underlying QoS architectures and also provide swappable modules to support different QoS setups for diverse applications. Currently, TQM is implemented on UNIX platform and some important issues of applying TQM in IntServ/DiffServ networks have been examined. Keywords: multimedia application, transparent QoS, IntServ, and DiffServ 1. Introduction As the increasing bandwidth of link and the rapid integration of various emerging networking technologies, multimedia services such as real-time audio/video streaming are more popular. Since multimedia applications are typically more sensitive to packet loss, delay and jitter than elastic ones, multimedia applications thus have more strict QoS requirements for packet transmission. To deploy QoS in the Internet, the underlying QoS architecture, QoS management system, and QoS-aware application are necessary. IntServ (Integrated Service) [1] and DiffServ (Differentiated Service) [2] are two well-known architectures to support QoS in IP networks. QoS management system provides the essential functionalities for applications to access underlying QoS architectures as well as system resource based on the support of QoS API and middleware [4]. Additionally, an application is said to be QoS-aware if it can enable to specific QoS functionalities of IntServ/DiffServ networks. In IntServ, applications should signal RSVP control messages along data path to allocate resource based on individual traffic specification. On the other hand, applications could identify desired QoS class in DiffServ by means of pre-marking the appropriate DSCP (DiffServ CodePoint) value in the TOS (Type of Service) field of IP packet header or providing useful indication to notify edge nodes [10]. This pre-marking/indication strategy at end system is important since the content of multimedia applications such as the MPEG-4 with multiple objects and user interactivity is complex. In order to reduce the processing complexity of edge nodes, it is more suitable for applications themselves to give indication information for packet marking while maximizing user s perceptive quality. Since the packet pre-marking behavior also makes indication possible, the pre-marking strategy is mainly considered in this paper. While QoS functionalities are available to establish QoS sessions, it remains opaque for QoS-aware applications to describe required QoS parameters for resource allocation or service differentiation. For video streams, multimedia applications may be transmitted over VBR (Variable Bit Rate) service; it is difficult to allocate the desired resource due to the tradeoff between the network utilization and the quality guarantee. For complex multimedia applications such as MPEG-4 programs, multiple objects of the same media or distinct media within one application flow generally have different QoS requirements. Furthermore, multicast applications require multiple flows because of the layer coding and transmission [9]. The corresponding service levels within one flow or among multiple flows are thus necessary to be identified for packet marking to provide the service differentiation. To solve this deployment problem for diverse applications, one could directly upgrade the legacy applications, which costs a lot of efforts. In [3], by adopting so-called QoS Library Redirection (QLR), applications can set up QoS without source code modification but the application-depend libraries may /04/$ IEEE. 233

2 need to be built individually. In this paper, a Transparent QoS Mechanism (TQM) is proposed for multimedia applications to take benefits of underlying IntServ/DiffServ networks. With TQM, applications are transparently to be QoS-aware without any modification. In addition, TQM provides a flexible mechanism to transparently swap suitable QoS module to determine desired QoS parameters for diverse applications. In IntServ, RSVP control message is signaled based on dynamic resource allocation schemes. As to DiffServ, differentiations within one flow and among multiple flows are supported to further utilize packet marking schemes. This paper is organized as follows. Section 2 introduces the overview of TQM. The components of TQM are described in Section 3. Prototype implementation in Unix platform is presented in Section 4. Section 5 shows the performance issues of experimental results about TQM. Finally, Section 6 concludes this paper. 2. Transparent QoS Mechanism (TQM) The proposed TQM provides transparent interaction with underlying QoS architecture for Internet multimedia applications. For establishing RSVP sessions in IntServ or pre-mark packets to service classes in DiffServ on behalf of applications, TQM is sender and application level-based. As Figure 1 depicts, the diversity of applications and underlying architectures are both concealed by two modules of TQM: Flow State and QoS Manager. When applications are launched, some records would be created in kernel for system communication and maintenance. Without modifying kernel and applications, Flow State is a virtual module which collects flow information from these records provided by kernel. As this information is presented to QoS Manager, user can interact with QoS Manager to specify which application requires QoS support. QoS Manager then applies information of Flow State to transparently establish RSVP session in IntServ or pre-mark IP packets to proper DSCP in DiffServ on behalf of applications. 2.1 TQM in IntServ with RSVP To establish a RSVP session in IntServ, both sender and receiver need to communicate the PATH and RESV signaling messages hop-by-hop along the data path. Typically, a common RSVP API (RAPI) is provided for applications to interact with the RSVP daemon that is responsible for policy and traffic control. While applications trigger QoS requests by RAPI, RSVP daemon will issue associated PATH signaling message with appropriate traffic specification. Comparatively, the receiving applications can send RESV signaling message back to specify the QoS it wishes to receive. Thereafter, the desired resource is allocated by each hop to guarantee requested QoS. Therefore, there are two necessary modifications for legacy applications to be QoS-aware. The first one is to describe flow parameters required by RAPI function calls for flow identification such as IP addresses and port numbers. Another is to specify QoS parameters to allocate desired resource according to traffic specification. TQM intends legacy applications to be transparently QoS-aware. In Figure 1, an agent called QoS Manager is used to react user input and setup QoS for applications; it collects the information of Internet applications and displays to user. Thus, user could determine which flows need to request QoS. QoS Manager then sends the PATH signaling message on behalf of user-specified legacy application by describing flow parameters according to the available information from Flow State, and providing appropriate traffic specification based on resource allocation scheme. It is noted PATH message from sender is used to discover RSVP-aware neighbors, advertise their capabilities, and install state relevant to the data flow. The resource allocation is indeed made by RESV message from receiver; therefore an agent has to be installed in receiver to obtain the traffic specification by parsing received PATH message and then send RESV message with desired QoS parameters. Figure 1. The communication model of TQM 2.2 TQM in DiffServ DiffServ provides both the guaranteed and relative QoS by dividing packets into different service classes and /04/$ IEEE. 234

3 forwarding them as different priorities. Therefore, IP packets with similar DSCP identify one aggregate behavior. Packets can be pre-marked at the host end and re-marked at the ingress router of DiffServ domain. Typically, there are different QoS requirements or importance levels for multimedia packets. For example, the packets of I frame have precedence for QoS guarantee over the packets of P and B frame within a MPEG video session. Some complex multimedia applications such as MPEG-4 programs require multiple objects of the same media or different media. These objects may need differential quality of service for packet transmission. To accommodate this scenario, it is necessary to provide differentiation among multiple flows and within one flow. Intuitionally, packets with different transmission requirements could be divided into different layers. To transport the layered packets, several IP sessions may be created and proper DSCP values are marked for each individual IP session. Multiple channels are thus required for such layered coding and transmission [9]. However, applications need to coordinate the synchronization among multiple channels and it is also complicated to maintain large session states. For multicasting transmission, the multi-flow differentiation is quite suitable for heterogeneous receivers. An alternative is to support differential marking within one flow; packets that belong to one application flow are marked to corresponding DSCP values respectively according to their different requirements. Therefore, objects or packets of different layers could be multiplexed and then transported into one IP session. To be QoS-aware, two modifications for legacy applications are required: The first one is to identify which packets need what service levels, and another is to call the setsockopt() function to pre-mark the identified packets with corresponding DSCP values before transmission. In TQM, QoS Manager marks flows that are identified by the available information of Flow State to achieve differential marking. Additionally, the differentiation within one flow is provided without modifying applications by transparently diverting packets from IP layer to application layer (see Figure 1), and then the assigned DSCP value is directly set to an identified IP packet. After packets are pre-marked to appropriate DSCP value, they are injected into general network protocol stack for transmission. In this way, TQM could accurately identify and mark packets with their different QoS requirements and only one IP session is needed. A possible problem for TQM is the disorder of IP packets within the same flow due to different transmission priorities. It is noted that connectionless characteristic of IP protocol may also lead packet disorder and the recovery process is straightforward. 3. TQM Architecture In TQM, transparent QoS establishment is provided by data plane and control plane. In data plane, user-specific flow is identified and the relative information is available to underlying QoS process. Control plane is able to setup QoS sessions on behalf of applications in IntServ/DiffServ networks. Therefore, legacy applications are totally transparent to be QoS-aware. Figure 2 shows the components of TQM. Figure 2. The TQM architecture 3.1 Data plane There are three components for flow information management in data plane: Application Filter, User Interface, and Application Database. User registers application to Application Database through User Interface, and Application Filter collects flow information of the launched applications from Flow State. By querying Application Database, Application Filter discards some flow information that is not registered by user. Only registered and launched flows are presented to user in User Interface; thereafter, user can further specify the flow for QoS support at any time. Application Database Applications may not all have strict QoS requirements, such as DNS query, time service, and http service etc., hence TQM uses Application Database to record some multimedia applications specified by user to request QoS support. User can register specific applications to Application Database through User Interface, and arbitrarily add or delete the registration records from database on demand. With this database, Application Filter only retrieves the information of those identified user-specific flows /04/$ IEEE. 235

4 Application Filter Application Filter gets the essential flow information required to transparently start QoS sessions on behalf of applications. Generally, this information may be based on 5 tuples (transport protocol, source IP address, source port, destination port, and destination address). If user confirms a specific flow to request QoS support, this information is available to control plane for QoS session establishment. 3.2 Control plane Two components are presented in control plane to transparently specify desired QoS parameters. In IntServ with RSVP, Resource Allocator reserves network resource by signaling RSVP messages. In DiffServ, Packet Marker redirects IP packets for differential marking. It is important to note that Resource Allocator and Packet Marker are both swappable modules. Any suitable algorithms to allocate resource in IntServ or to mark packets in DiffServ could be chosen arbitrarily. TQM thus provides a flexible and efficient mechanism for diverse applications. Resource Allocator Resource Allocator establishes RSVP sessions, which require flow parameters for flow identification and QoS parameters to describe desired resource for QoS guarantee. Flow parameters are simply provided by flow information in data plane. To determine QoS parameters, there are many related works about resource allocation scheme of multimedia applications: For VBR traffic, the dynamic resource allocation scheme in [5] aims at providing QoS guarantee as well as better network utilization. Based on the information of traffic characteristics, resource allocation schemes would predict desired resource with proper QoS parameters. Traffic Meter is thus located at control plane to monitor the user-specific flow and to provide its traffic statistics to Resource Allocator, since TQM requires Resource Allocator to swap suitable resource allocation scheme for diverse multimedia applications. Packet Marker Packet Marker marks packets in DiffServ according to marking algorithms. Owing to the complex content of multimedia applications, marking algorithms mark packets with different QoS requirements to different service classes [6-7]. To be swappable among marking algorithms, Packet Marker supports differential marking within one flow and among multiple flows. Based on the flow information from data plane, Packet Marker can easily identify flows. For multiple flows, Packet Marker simply calls the setsockopt() function to mark packets of each individual flow. For one flow, Packet Marker redirects IP packets of a user-specific flow and updates TOS filed of each packet with appropriate DSCP value. After marking, TOS-modified packets are sent back to network protocol stack for transmission. 4. Prototype Implementation The prototype implementation of TQM was developed on FreeBSD and Linux platforms. We have implemented two module prototypes of TQM: QoS Manager and Flow State. All components of these two modules are shown in Figure 3. User Interface: implemented in GTK+. Flow State and Application Filter The Flow State module provides a set of flow information from kernel. Different platforms support different file access or system calls to describe the network connections such as fstat, netstat, and sockstat, etc. Once applications are launched, Application Filter will compare the registration records with the system records provided by Flow State to obtain the desired information for flow identification. Traffic Meter Traffic Meter was implemented in the functionality of IP firewall, which provides flow accounting. There are many approaches to implement Traffic Meter, such as Packet Capture Library (PCAP); however, these approaches have to intercept every packet through network interface up to application level, which leads much system overhead. Therefore, obtaining traffic statistics from IP firewall in kernel should be a more efficient way. Packet Marker Packet Marker was implemented in the functionality of IP firewall as well as divert socket; Divert socket is one element of general BSD socket. Since IP firewall is located in the bottom of IP stack, it redirects IP flows to a specific system port. Packet Marker employs divert socket to bind this specific port and then receives data packets from it. While Packet Marker updates the value of TOS field in IP header, it also needs to pay attention to some IP fields that validate the packet correction such as checksum. Figure 3 shows the GUI of QoS Manager of TQM. There are four blocks in QoS Manager: flow block, QoS flow block, QoS setting block, and application registration block. User can add any flows identified by Application Filter in flow block to the QoS flow block. QoS Setting Block provides user to choose service type for some flow. We have currently implemented LMS predictor to dynamically allocate resource for VBR video in IntServ [5] and also differential marking for video applications in DiffServ [6]. Two target applications in Figure 3 are vic (a video conferencing tool) and vls (a video-on-demand tool) respectively /04/$ IEEE. 236

5 of these two cases is 16.7 and ms, which is approximate to the results proposed in [8]. In the Loaded case, a hundred of best-effort flows with packet size 50Kb are joined to occupy half of link bandwidth. T setup is grown to ms, which is a factor of 5.18 compared to the Unloaded case. Table 1. Session setup time (T setup ) with RSVP Experiment Cases T setup (ms) Pure 16.7 Unloaded Loaded Figure 3. Snapshot of TQM 5. Experimental Results 5.1. Resource Allocator and RSVP Dynamic resource allocation scheme renegotiates desired resource while the resource requirement is changed. The time period between two renegotiations is called renegotiation interval. When Resource Allocator establishes a RSVP session to renegotiate resource, there is a session setup time to process PATH and RESV messages. It is important to understand the correlation between the renegotiation interval and session setup time. Obviously, the effectiveness of resource allocation is achieved only if the session setup time is smaller than the renegotiation interval. The session setup time, T setup, is defined as the delay between the time when a PATH message is presented at sender s local network interface and the time when the corresponding RESV message is presented at the same interface. There are two components of delay in T setup : message processing delay and link propagation delay. This paper denotes the processing delay of PATH (RESV) message in a router by T path (T resv ), the processing delay of PATH and RESV message in receiver by T recv, and the link propagation delay by T prop. Thus, the session setup time can be expressed as below: T setup = N T path + N T resv + T recv + 2 T prop where N is the number of routers between sender and receiver. To further measure the session setup time of RSVP, an experiment is done on a simple LAN testbed which includes a sender, a receiver, and two Cisco 2600 routers. The speed of all links connecting hosts and routers are 10Mbs. Table 1 shows the experimental results of average session setup time measured on the sender. In the Pure case, there is no traffic in the link except control messages of one RSVP session. The Unloaded case involves several RSVP sessions but only RSVP control messages are generated. In Table 1, T setup In order to achieve the effectiveness, dynamic resource allocation schemes thus require the renegotiation interval to be larger than T setup in Loaded case. For dynamic resource allocation of VBR video, some conventional approaches renegotiate resource on a frame basis. Since the typical frame rate of video playout is generally from 25 to 30 frames per second, the renegotiation interval is thus within 33 ms and 40 ms. Additionally, it is important to note that T setup will be increased in WAN environment and its measurement results are also varied with different testbeds. Therefore, the renegotiation interval is recommended to be at least on a GOP or even longer time period basis when a dynamic resource allocation scheme is applied with RSVP. Figure 4. Testbeds 5.2. Packet Marker Packet Marker adopts flow redirection to support differentiation within one flow. Packets would be copied from kernel space to user space and then sent back to kernel space for transmission. This processing overhead thus causes the additional delay. For multimedia applications, delay is one of the major factors to influence the perceived quality. To observe the required overhead of Packet Marker, the average delay time of flow redirection is estimated with variable packet size. As Figure 4 shows, Host A sends ICMP ping requests to Host B, and waits for echo responses. There are two Cisco 2600 routers between two hosts. Each echo response would be redirected to Packet Marker and then marked for transmission. In Host A, the RTT is measured to calculate the difference between redirection and /04/$ IEEE. 237

6 without redirection. Table 2 shows the experimental results. As the packet size is increased, the time difference between redirection and without redirection is also increased. However, there is only a small increase to the original RTT without redirection. For the case of 1024 bytes, which is around the typical packet size of multimedia applications, the increase percentage is 0.276%. Compared to the transmission and processing delay, the overhead of flow redirection is relatively minor. Table 2. Overhead of flow redirection Next, the second experiment is conducted to observe whether the redirection delay of each packet would accumulate to affect the playout time of multimedia applications. With the same testbed in Figure 4, Host B streams a long-lived MPEG video to Host A. Packets that belong to I, P and B frame are redirected and marked to three different priorities for transmission. In Host A, the total playout time is estimated to compare with the case without redirection. Table 3 shows the results of four video sequences under testing. The redirection delay of total playout time is no more than 0.2 second. Actually, this minor delay would be easily absorbed by the application buffer and won t affect the user s perceived quality. Since the Host B operates with P-4 1.8G and 256 MB memory, we believe that the possessing power of current machine is enough for TQM to support differential packet marking within one flow. Table 3. Cumulative delay with flow redirection 6. Conclusions In this paper, we have proposed TQM in end host to transparently establish QoS session on behalf of multimedia applications in IntServ/DiffServ networks. Without modifying legacy applications, TQM not only communicates with underlying QoS architectures but also can provide swappable modules to support different QoS setups for diverse applications. In IntServ with RSVP, dynamic resource allocation schemes are mainly considered. In DiffServ, differentiations among multiple flows and within one flow are both supported. Experiments results show the guide to determine the suitable module of dynamic resource allocation schemes with RSVP. Also, the performance overhead of flow redirection to support differential marking within one flow is showed to be minor. We believe that TQM can complement the QoS management system to facilitate the deployment of underlying QoS architectures. Currently, TQM has implemented on the UNIX-like platform. The future work is to apply TQM to the residential gateway. Meanwhile, more proposed modules for QoS provisioning in IntServ/DiffServ domains would be discovered. References [1] J. Wroclawski, The Use of RSVP with IETF Integrated Services, RFC 2210, Sep [2] S. Black, D Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An architecture for Differentiated Services, RFC 2475, December 1998 [3] C.K.Shieh, Y.B. Miao, C.Y. Wang, W.S. Hwang, J.F. Chiu, A Transparent Deployment Method of RSVP-aware Applications on Unix, Computer Network, vol. 40, Issue: 1, Sep. 2002, pp [4] Nikolaou, N.A.; Tsetsekas, C.A.; Venieris, I.S., A QoS middleware for network adaptive applications, IEEE International Conference on Multimedia Computing and Systems, June 1999 [5] A.M. Adas, Using adaptive linear prediction to support real-time VBR video under RCBR network service model, IEEE/ACM Trans. on Networking, Vo. 6, No. 5, Oct [6] Octavio Medina, A DiffServ-aware Video Streaming Application, available on line [7] Ahmed, T.; Buridant, G.; Mehaoua, A., Encapsulation and marking of MPEG-4 video over IP differentiated services, Proceedings of Sixth IEEE Symposium on Computers and Communications, July 2001 [8] A. Neogi, T. Chiueh, P. Stirpe, Performance analysis of an RSVP-capable router, IEEE Network Magazine, Vol. 13, Sept.-Oct [9] V. Jacobson S. McCanne and M. Vetterli, Receiver-driven Layered Multicast, In Proc. of ACM SIGCOMM, August 1996 [10] Sung-Hyuck Lee et al, Study of TCP and UDP Flows in a Differentiated Services Network Using Two Markers System, IFIP/IEEE MMNS, Sept.-Oct /04/$ IEEE. 238