Price-Sensitive Application Adaptation in Deadline-Based Networks

Transcription

1 Price-Sensitive Application Adaptation in Deadline-Based Networks Xiao Huan Liu Department of Computer Science University of Manitoba Winnipeg, MB R3T 2N2, Canada Yanni Ellen Liu Department of Computer Science University of Manitoba Winnipeg, MB R3T 2N2, Canada Abstract In deadline-based networks, the delay performance experienced by real-time data transfer largely depends on traffic deadlines and the load level along the data transfer path. To ensure fairness among users and to aid in network load control, a delay pricing and charging scheme was developed for realtime delivery in deadline-based networks; users experiencing different delay performance are charged differently and the charge is higher when the load is heavier. In response to an earlier charge, a price-sensitive adaptive application with limited budget constraints may adjust its traffic accordingly by varying traffic deadline requirements or traffic load intensity. We study the effect of application adaptation in two real-time traffic scenarios: discrete real-time documents, and a mixture of on-line game and multimedia traffic. We show through simulation that the aforementioned pricing and charging scheme easily enables user adaptation, which in turn may significantly improve the network delay performance. I. INTRODUCTION Deadline-based network resource management [9] is a framework that has been developed to support real-time data delivery in packet-switched networks. In this framework, each application data unit (ADU) is given a delivery deadline by the sending application. It represents the time at which the ADU should be delivered at the receiver. Depending on the maximum packet size of the underlying network, an ADU may be segmented into multiple packets for transmission. The ADU deadlines are mapped to packet deadlines, which are carried by packets and used by routers for channel scheduling. Deadlinebased channel scheduling algorithm is used inside routers. It was shown that deadline-based scheduling achieves superior performance to FCFS (First-Come First-Served) with respect to the percentage of ADUs that are delivered on time [7]. In deadline-based networks, the delay performance observed by real-time data largely depends on the deadline that it carries. If one is free to specify ADU deadlines, a sender may try to gain an advantage by using arbitrarily tight deadlines. Besides deadline urgency, the delay performance in deadline-based networks is also affected by the load conditions along the ADU path. When the load is light, the delay performance is good. When the load is heavy, congestion may occur; the delay performance deteriorates. To prevent greedy users from specifying arbitrarily urgent deadlines and to aid in network load control, a novel delay pricing and charging scheme was developed [6]. In this scheme, a market-based approach from the field of microeconomics was taken. Each channel periodically computes a channel delay price based on the relation between the delay supply and the delay demand. The delay supply S is derived from the total time it takes to service all the packets in a price update interval. The delay demand D is derived from the deadlines carried by these packets. At the end of the update interval n, the channel delay price p for the update interval n + 1 is defined as: p n+1 = {p n + σ (D S)/S,0} +, where σ is an adjustment factor that can be used to trigger faster or slower responses of the channel price to the amount D S. With this scheme, the channel price is higher (i) when the deadline urgency is higher, and (ii) when the load is heavier. Given this pricing scheme, packets and ADUs are charged as follows. At each channel, upon each packet departure, the packet response time d r (which is defined as the sum of the queuing delay, the packet transmission time, and the channel propagation delay) at this channel is calculated. Let p be the current channel delay price. The packet delay charge g at this channel is defined as: g = p/d r. A new packet header field called accumulated charge is defined to keep track of the total delay charge incurred by this packet at all channels along its path. If a packet arrives at the receiver on-time, the value of this field is retrieved and is taken as the packet charge. If an ADU is delivered on-time, its ADU charge is the sum of all its packets charges. Late ADUs are not charged. In response to the charges assigned by the network to earlier transmissions, a price-sensitive adaptive application with limited budget constraints may adjust its traffic by varying its traffic deadline requirements or load intensity. In this paper, we first present an example user adaptation model for real-time traffic. We then use simulation to show that such adaptation, which is enabled by the aforementioned delay pricing and charging scheme, may significantly improve the on-time performance in deadline-based networks. II. PRICE-SENSITIVE APPLICATION ADAPTATION In a network that has a service pricing and charging scheme in place, users are usually price-sensitive; users may adapt their traffic in response to price changes. If users cannot afford their transmissions given the current price, they either lower their transmission quality requirements, lower their traffic, or

2 opt not to transmit. Conversely, if users have abundant budget, they may raise their transmission quality requirements to gain a better service or increase their traffic to accomplish more tasks. In what follows, we focus on applications that may adapt their traffic requirements. We first describe an example user adaptation model. Note that our goal is not to come up with an accurate or even a good user adaptation model, but rather to use a somewhat reasonable one to demonstrate the potential of application adaptation in network load control. In our example adaptation model, we assume that application adaptation is performed periodically at regular time intervals, called adaptation intervals. We assume that each user (or application) has a fixed amount of budget for every price update interval called interval budget. The ADU charges are made available to the senders via application-layer acknowledgments (ACKs), and each user records the total charge that is received in every price update interval. Each sender also records the number of on-time ADUs (N t ) based on ACKs and the number of ADUs sent (N) per adaptation interval. Denote each source/destination pair in a network as a traffic class. And denote a sequence of ADUs that belong to the same traffic class as a session, which may represent the traffic of a real-time application. We assume that each session specifies an expected level of ADU on-time rate, EptRate. When the value of N t /N is greater than EptRate, a session is regarded as receiving satisfactory delay performance in the previous interval. Otherwise, a session is deemed unsatisfied. We also define a threshold budget parameter β to quantify the ratio of interval charge and interval budget. Our adaptation model operates as follows. If a session s charge (IC s )in the previous interval is lower than β percent of the session s interval budget (IB s ) and the value of N t /N of the session in the previous interval is greater than the session s EptRate, which indicate that the session has abundant budget and received satisfactory delay performance, the session performs adaptation by increasing its service requirement. Conversely, if a session s charge in the previous interval is greater than the session s interval budget or the value of N t /N of the session in the previous interval is lower than the session s EptRate, which indicates that the session does not possess enough budget or the session received unsatisfactory delay performance, the session performs adaptation by decreasing its service requirements. If the charge is in between β percent and 100% of the interval budget and the value of N t /N of the session in the previous interval is at least the session s EptRate, no adaptation is carried out. The pseudo code for session adaptation is given as follows: FUNCTION (Session-Adaptation) IF (IC s > IB s ) OR ( Nt N < EptRate) Decrease the session s traffic requirement IF (IC s < β IB s ) AND ( Nt N > EptRate ) Increase the session s traffic requirement Based on the charge and delay performance received in the previous adaptation interval, we assume that a sender can adjust one or more of the following three attributes for its subsequent traffic: the ADU deadline urgency level, the ADU sending rate, and the ADU size. When the budget is lower than the charge received in the previous interval or when the delay performance in the previous interval is unsatisfactory, a user may lower its traffic requirements in terms of less urgent deadlines, a lower ADU sending rate, and smaller ADUs. When deadlines are less urgent, its priority in deadline-based scheduling would drop, the response time would increase, which results in a lower charge; when the ADUs are sent at a lower rate, fewer ADUs are sent every fixed time interval, thus a lower charge; when ADUs are smaller, the network load level can be reduced, the mismatch between the delay demand and the delay supply would decrease, which results in lower prices and lower charges. Conversely, when the budget is greater than the charge received in the previous interval and the delay performance in the previous interval is satisfactory, a user can raise the requirements of his/her traffic. The exact algorithms for increasing or decreasing service requirements are application-traffic specific. In the next section, as proof of concept, we study two types of application traffic. III. PERFORMANCE EVALUATION We use discrete event simulation to evaluate the on-time performance when with adaptation. In our evaluation, two types of application traffic are experimented: discrete real-time ADUs and a mixture of real-time on-line game traffic and continuous-media traffic. The former represents generic realtime traffic while the latter represents a more realistic traffic mix. We first describe the performance model. The case when there is no application adaptation serves as the benchmark scenario to be compared with. A. Performance Model We first describe our network model. The traffic model for the two traffic scenarios will be described in the following two subsections respectively. A 13-node network model is used in our experiments. Its topology is depicted in Fig. 1. The capacity of each channel is assumed to be 155 Mbit/second Fig Network model The number shown on each link is the distance in miles. It is used to determine the propagation delay. The propagation speed is assumed to be 120 miles/ms. Each scheduler employs the T/H channel scheduling algorithm [7]. Fixed routing is assumed. At each channel, a finite buffer is in place. Modern

3 routers usually have large buffer sizes that can accommodate between 100 and 200 ms worth of data with respect to link capacity [3]. In our simulation, the buffer size was assumed to be 3.1 Mbyte for each outgoing channel. This corresponds to 160 ms worth of data with respect to the link capacity. For simplicity, we assume that packets dropped due to buffer overflow and late packets are not re-transmitted. In our simulations, we assume that the user adaptation intervals coincide with the price update intervals. We also assume that no ACK is lost and the end-to-end delay of ACK packet is uniformly distributed on the range of [35, 85] ms. This range is selected based on the longest end-to-end propagation delay, which is about 32.8 ms in our network. B. Case I: Discrete Real-Time Document Traffic The first type of traffic that we evaluate consists of discrete real-time ADUs. We describe the traffic model, the adaptation algorithm, and the performance evaluation in turn. Without loss of generality, we assume that there is one session per traffic class in our network. Each session continuously generates ADUs during the entire simulation duration. The ADU deadlines are given by deadline = arrival time + (1 + expo(d))x, where x is the sum of the ADU end-toend propagation delay and the ADU end-to-end transmission delay, and expo(d) represents an exponentially distributed random variate with mean d. We call parameter d the deadline urgency parameter. The ADU interarrival time of each session is assumed to be exponentially distributed with mean I. The ADU size is the product of θ and a random variate z, in Kbytes. θ is a parameter whose value increases (or decreases) when service requirement is increased (or decreased) in application adaptation. z is generated from Uniform(0.5, 1.5) and Uniform(1.5, 500) with equal probability. Thus the following attributes are associated with each session and are adjusted in application adaptation: 1) deadline urgency parameter d, 2) mean ADU interarrival time I, and 3) ADU size parameter θ. In our experiments, when with adaptation, for all sessions, the initial value of d is set to 0.4, the minimum value of d is set to 0.2, and there is not an enforced upper bound on the value of d. All initial values of I are 0.08 seconds, which corresponds to an offered load level of 1.01 on the bottleneck when without adaptation. There is not an enforced upper bound and lower bound on the value of I. The initial value and the maximum value of θ are set to 1, there is not an enforced lower bound on the value of θ. The increase or decrease of service requirements is modeled as follows. Define an adaptation parameter α. Let the value of an attribute in the update interval n be v n. The value of the attribute in the update interval n + 1, v n+1 is calculated by v n+1 = v n (1 + α), or v n+1 = v n (1 α) (1) In Case I, α value of 0.4 is used. To evaluate the ADU on-time performance when with adaptation, four experiments are performed: one without adaptation, in the other three, the three attributes: d, I, and θ are adapted respectively. The price update interval and the adaptation interval are assumed to be 1 second long. The initial price at each channel is assumed to be zero. All sessions interval budget is assumed to be 1. Note that we do not associate the price or charge with any concrete monetary value and leave this choice to network operators. The threshold budget parameter β for all sessions is 80, and the expected on-time rate EptRate for all sessions is 0.9. The simulation run length is 150 seconds. We assume that each sender starts to perform adaptation at time 10 seconds. This is to make sure that users begin their adaptation after the router buffers are filled to some degree. We use the aggregated on-time ADU throughput (in ADUs/sec) as our performance metric. It is defined as the total number of on-time ADUs across all traffic classes in the network divided by the simulation time. The results from our simulation are shown in Table I. TABLE I PERFORMANCE WITHOUT AND WITH ADAPTATION (CASE I) Adaptation attribute ADU On-time throughput (ADUs/second) Without adaptation Adapting deadline d Adapting inter arr t I Adapting ADU size θ It can be observed that the performance can be improved with application adaptation. We also plot the price dynamics over time on the bottleneck when without and with adaptation in Fig. 2. We observe that the channel delay price on the bottleneck can be well controlled when with user adaptation, in contrast the price keeps increasing when without adaptation. price Without adaptation With adaptation on deadline With adaptation on mean ADU interarrival time With adaptation on ADU size Fig. 2. time(sec) Channel delay price, Case I C. Case II: A Mix of On-line Game and Multimedia Traffic The traffic scenario in Case I represents a generic type of traffic with ample space for traffic attribute adaptation. In more realistic traffic scenarios, each user may open multiple real-time applications together, and each real-time application may have its own traffic characteristics. In particular, some parameters may not be adapted or may only be adapted within a small range. For example, a video application sends video frames at a rate of 25 frames/second to the network, in this case each video frame can be considered an ADU, and arbitrarily increasing or decreasing the ADU sending rate may not be possible. In addition, if an application can no longer

4 adapt its traffic parameters, it may be wise to temporarily pause the session, later when network load drops, the stopped session may be resumed. In this section, we experiment with a more realistic traffic scenario in which both on-line game and multimedia traffic are involved. We first describe the traffic model used and the adaptation model assumed, experiments and results are reported afterwards. There are three types of session in the traffic mix: realtime interactive game, interactive multimedia, and streaming stored multimedia. For game sessions, we use the traffic model in [4]. In multiplayer interactive games, when players make moves, state update messages are sent from game clients to the game server, and then forwarded by the server to other affected game clients. Each state update message can be considered an ADU. The traffic model is slightly different between the game clients to game server traffic and the game server to game clients traffic. For simplicity, in this study, we only include the game clients to game server traffic in our traffic model. The ADU interarrival times are bimodal, half of which are 33 ms fixed, the other half are 50 ms fixed. The two values randomly alternate. The ADU sizes follow a normal distribution with mean of 72.3, and standard deviation of 7.0, in bytes. For the multimedia sessions, in our experiments, 10 video traces from [1] are used. A variety of videos are included, there are drama movies, action movies, cartoon movies, TV shows, sports, and office camera video. Each trace includes three trace files, corresponding to the low, medium, and high quality levels of the same video respectively. A lower quality trace normally has smaller frame sizes than a higher quality trace. We use Q to denote the quality level of a video; three values of Q: 1, 2, and 3, are used to represent the low, medium, and high qualities respectively. Each trace consists of ADU sizes of video frames, in bytes. These frames are captured at a rate of 25 frames/second. Therefore the ADU interarrival time for multimedia traffic is 0.04 second. Let end-to-end deadline D denote the time interval between ADU arrival at the network and its deadline. Given D, the frame deadline is D plus the arrival time. All frames in a session have the same value of D. For each session, the initial D=(1+expo(d))*x p, where x p is the end-to-end propagation delay. Differ from the method in Case I, we do not consider the transmission delay, this is because the ADU sizes are relatively small, the transmission delay is much smaller than the propagation delay and is ignored. Each session has a minimum value of D (mind) and a maximum value of D (maxd). The end-to-end deadline of a session s ADUs can only be adapted within the range from mind to maxd. mind uses a d value of 0.3. For game sessions and interactive sessions, the maxd is 0.2 seconds; for the streaming sessions, the maxd is 10 seconds. In our experiments, a session s initial D is its mind. For the game sessions, it is not reasonable to adapt ADU sizes and ADU interarrival times, thus only end-to-end deadline parameter D can be adapted. For the multimedia sessions, because the play-out process requires that the multimedia frames be played back at the rate of 25 frames/second, it is not reasonable to adapt ADU interarrival times, thus only end-toend deadlines and ADU sizes can be adapted. For ADU sizes, we assume that an application can adapt by using a frame from a higher or a lower quality traces of the same video, i.e., Q is either increased or decreasing by 1. For all session types, we adapt D using Eq.1. For multimedia sessions, D will be adapted first, if D has reached the maximum or minimum value, which indicate D cannot be adapted further, Q is adapted. If no attributes of the session can be adapted during the lowering of the service requirement, the session is stopped in our adaptation model. A user can send traffic across multiple traffic classes from the same source. Along each traffic class, a user may initiate multiple sessions. To simplify the simulation, there is only one user on each traffic class, and a user generates a number of sessions belonging to the same traffic class at the beginning of simulation. All sessions continuously transmit ADUs during the entire simulation run except being stopped by their user, this way sessions perform the adaptation during the entire simulation. Each user has an interval budget. A user s interval budget (IB u ) is the sum of all his/her sessions interval budgets. A user s charge (IC u ) in an adaptation interval is the sum of all his/her sessions charges in the adaptation interval. If IC u is less than β*ib u and the user has stopped sessions, the earliest stopped session is resumed. In addition, each ongoing session of this user performs adaptation. If IC u is greater than β*ib u (this includes the case when IC u is greater than IB u ), normal session adaptation described above is performed. The pseudo code for user adaptation is given below: FUNCTION (User-Adaptation) IB u = user.ib s, IC u = user.ic s ; IF (IC u < β IB u ) AND (has stopped sessions) Resume the earliest stopped session FOR all user s sessions Perform session adaptation Two experiments are carried out to evaluate the performance gain when with application adaptation. In the first experiment, the number of sessions of a user is uniformly distributed on [10, 30], and the offered load on the bottleneck is 0.98 without user adaptation. In the second experiment, the number of sessions of a user is uniformly distributed on [10, 40], and the offered load on the bottleneck in this case is 1.27 without user adaptation. With these two levels, we can observe the adaptation behavior when the network load is heavy and when the network is overloaded. In both experiments, among all sessions in the network, 10% of them are game sessions, 70% of them are interactive multimedia sessions, and 20% of them are streaming multimedia sessions. At the beginning of simulation, a multimedia session randomly chooses a video from the available 10 videos, there are 50% of multimedia sessions use trace files in high quality, there are 30% of multimedia sessions use trace files in medium quality, and there are 20% of multimedia sessions use trace files in low quality. Two values of EptRate: 0.7, 0.9, and two values of α: 0.4 and 0.8 are experimented. The values of interval budget,

5 adaptation and price update interval length, β, simulation run length are all same as the values in Case I. The results for the first experiment are shown in Table II. Results for the other experiment show similar trend. We report TABLE II WITHOUT AND WITH ADAPTATION, NO. OF SESSIONS: [10,30] Adapting attributes Aggregated ADU ontime rate Lowest ADU ontime rate of a user On-time ADU throughput Offered load on bottleneck Without adaptation 66.10% 14.09% (α=0.4) (EptRate=0.9) 86.48% 72.51% (α=0.8) (EptRate=0.9) 82.58% 63.50% (α=0.4) (EptRate=0.7) 78.39% 48.87% (α=0.8) (EptRate=0.7) 75.65% 48.84% both ADU on-time throughput and ADU on-time rate. The ADU on-time rate is defined as the fraction of total ADUs sent that are delivered on-time. We collect the aggregated ontime throughput and ADU on-time rate, which are across all traffic classes in the network. We also collect the ADU on-time rate per user. In addition, we include the results for the user that had the lowest ADU on-time rate when without and with adaptation. We also include the offered load which is obtained from measurement on the bottleneck to show the average level of network load. From the results, it can be observed that by way of application adaptation, both the aggregated on-time performance and individual users on-time performance can be significantly improved. In addition, we can observe that, smaller value of adaptation parameter α results in lower offered load and slightly better ADU on-time performance, and a higher value of EptRate results in a slightly lower level of offered load but much improved on-time performance. We also plot the price dynamics in this mixed traffic case, comparing the channel delay price on the bottleneck when price Without user adaptation With user adaptation (α=0.4 EptRate=0.9) With user adaptation (α=0.4 EptRate=0.7) time(sec) Fig. 3. Channel delay price, Case II, no. of sessions: [10,30]. without and with adaptation. The results for the first experiment is shown in Fig. 3. The graph for the other experiment is similar. It can be observed that the channel delay price can be well controlled when with user adaptation; in contrast, the price keeps increasing when without user adaptation. IV. RELATED WORK Price-sensitive application adaptation in packet networks has been studied previously. In [8], adaptation of bandwidth is performed by users to maximize utility when congestion pricing is in place. Differ from [8] and other work in the field where pricing and adaptation of bandwidth is concerned, we focus on traffic delay pricing and adaptation. This is made available by the deadline-based framework in which each packet carries its delay requirement. There is a large body of literature on network pricing serving goals such as maximizing revenue, achieving fairness, reducing congestion, thus improving transmission performance. Congestion condition is conveyed to end users by mechanisms such as the TCPlike congestion indication [2] and a congestion price. In the latter case, this price may be used in calculating the charge to users [8], which is the approach that we take, or it may only serves the purpose of congestion indication [5], which in turn affects network resource management strategies. Aspects of differences between our work and existing work include studies of single channel [2] versus of a general network environment; centralized resource management such as that at the access point in [5] versus distributed resource management in our work. Compared to long-lived flows [2], we also studied more realistic traffic scenarios. V. CONTRIBUTIONS We study the effect of application adaptation for two types of real-time traffic in deadline-based networks. Such application adaptation is enabled by a novel delay pricing and charging scheme developed for deadline-based networks. We assume that price-sensitive users with limited budget constraints will adapt their traffic requirements based on the charges and delay performance received earlier. We show through simulation that the delay performance of the entire network as well as each user can be significantly improved as the result of such adaptation. REFERENCES [1] [2] T. Basar and R. Srikant. Revenue-maximizing pricing and capacity expansion in a many-users regime. In Proc. of Infocom, [3] Internet end-to-end interest mailing list. Queue size of routers. [4] T. Lang, P. Branch, and G. Armitage. A synthetic traffic model for Quake3. In ACE 04: Proceedings of the 2004 ACM SIGCHI International Conference on Advances in computer entertainment technology, pages , New York, NY, USA, ACM Press. [5] R.R. Liao, R.H. Wouhaybi, and A.T. Campbell. Wireless incentive engineering. IEEE Journal on Selected Areas in Communications, 21(10), Dec [6] Y. E. Liu and X. H. Liu. A Delay Pricing Scheme for Real-Time Delivery in Deadline-Based Networks. In Proc. of the First Workshop on Internet and Network Economics (WINE), [7] Y. E. Liu and J. W. Wong. Deadline based channel scheduling. In Proc. of IEEE Globecom, pages , San Antonio, Texas, Nov [8] X. Wang and H. Schulzrinne. Incentive-compatible adaptation of internet real-time multimedia. IEEE JSAC, 23(2), Feb [9] J. W. Wong and Y. E. Liu. Deadline based network resource management. In Proc. of ICCCN, pages , 2000.