00001.tif

PDF

Download

Open document

Transcript (if available)

Content PRICIN G IN M ULTIPLE SERVICE CLASS CO M PU TER COMMUNICATIONS NETW ORKS by Ronald Paul Cocchi A D issertation Presented to the FACULTY OF TH E GRADUATE SCHOOL UNIVERSITY O F SOUTHERN CALIFORNIA In P artial Fulfillment of the Requirem ents for the Degree D O CTO R OF PHILOSOPHY (Com puter Science) December 1992 Copyright 1992 Ronald Paul Cocchi UMI Number: DP22844 All rights reserved INFORMATION TO ALL USERS T he quality of this reproduction is d ep en d en t upon the quality of the copy subm itted. In the unlikely event that the author did not sen d a com plete m anuscript and th ere are missing pag es, th e se will be noted. Also, if m aterial had to be rem oved, a note will indicate the deletion. Dissertation Publishing UMI DP22844 Published by P roQ uest LLC (2014). Copyright in th e D issertation held by the Author. Microform Edition © P roQ uest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United S ta tes C ode P roQ uest LLC. 789 E ast E isenhow er Parkway P.O. Box 1346 Ann Arbor, Ml 4 8 1 0 6 -1 3 4 6 UNIVERSITY OF SOUTHERN CALIFORNIA TH E GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES, CALIFORNIA 90007 This dissertation, written by & under the direction of h is. Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillment of re quirements for the degree of DOCTOR OF PHILOSOPHY Dean of G raduate Studies Date . . . A 22?......... DISSERTATION COMMITTEE ........... s i C hairperson p h . EL CpS 1 92 Cfe 59 37*9 p/.f-/ Acknowledgment s In m any respects this was the m ost difficult but m ost rewarding section to write. I have been fortunate to be associated with so m any com petent and intellectually stim ulating individuals throughout my life. I deeply regret th at I cannot acknowl edge all who assisted. I would like to express sincere thanks to my research advisor, D eborah Estrin, for her continued guidance, encouragem ent, support, and friendship during my gradu ate studies at the University of Southern California. Her rem arkable insight, high standards of scholarship, and intellectual integrity contributed substantially to the results presented in this dissertation. Professor E strin has always sought to put the interests of her students first, which can be extrem ely difficult in the world of academ ia. I was very fortunate to have had th e opportunity to work under her guidance during the past six years. I could not imagine how an advisor could have put forth more tim e and energy towards helping her students. I would also like to thank Scott Shenker and Lixia Zhang from Xerox PARC. Scott was like a second advisor to me. His dedication to this area of research and attention to detail has had a profound im pact on the models and results presented in this dissertation. We have spent countless hours discussing the m ost detailed aspects of this research. Lixia’s technical comments greatly strengthened the outcome of this work. She was also instrum ental in getting my m any sim ulation models off the ground. I wish to thank th e members of my qualifying exam ination and dissertation com m ittees: Bruce Abramson, George Bekey, Shahram G handelharizadeh, Greg Schwann, and David W aterm an for serving on these com m ittees and for their m any helpful comments and discussions while this work was in progress. Their contribu tions have enhanced th e quality of this research. I would especially like to thank| Professor Abramson for his insight and contributions in conducting interdisciplinary research. I am eternally grateful to the Hughes Aircraft Company for their financial sup port as well as providing me w ith a fertile work environment th a t has allowed me to grow both academically and professionally during the past six and one-half years. A company could not possibly have provided more support or a b etter educational fel lowship program. In particular I would like to express my gratitude towards Richard Loftus, Ron G illett, Kay Freeman, and Hank Doerfling who were instrum ental in obtaining for me the first Hughes Doctoral Fellowship in the history of the Infor m ation Systems Division. My managers: Gerry Hoshijo, Estella Me Elrath, Hank Doerfling, Ron Abe, and Wendell Oyama were gracious enough to let me establish my own work schedule for over six years while pushing myself through USC. I sincerely thank all the members, old and new, of the Network and D istributed Systems Laboratory at USC. I was fortunate to be a m em ber of this research group initiated by Professor Estrin. This community created a friendly, enjoyable, and stim ulating research environment. In particular, I would like to acknowledge several m em bers who were particularly helpful. I would like to thank my friend and coworker at Hughes, Danny Mitzel, who provided much help in classes and in the network lab. He convinced me to buy a SPARC Station. This was the best investm ent since my car. Gene Tsudilc for his continued inspiration and support. I attained to parallel his successes in m any ways during my tenure at USC: choice of advisor, taking the qualifying exam ination a few weeks before m arriage, honeymoon in Jam aica, and graduation, to nam e a few. Lee Breslau for providing much technical assistance and support through trying times. He always found tim e to lend a hand. Steve Hotz for providing systems help. His lighthearted humor helped make the long days much more enjoyable. Doug Fang for technical and systems help throughout my graduate career at USC. I would also like to thank Peter Danzig, Sugih Jam in, A bhijit Khale, Kraig Meyer, John Noll, K atia Obraczka, Bud Parer, Louie Ramos,j and Daniel Zappala for their help and friendship. Finally, Gary Frankel whosei m em ory provided inspiration to continue in the program and move on to w hatever1 challenges m ay follow. , I also wish to thank several friends, coworkers, and former instructors and fellow students. Charles Rieckhoff helped me throughout my undergraduate career at UCI. He is a true friend and was the best m an at my wedding. Amy Shishido B axter who got me started in the M aster’s program at USC the very next semester after graduating from UCI. She provided continued inspiration to continue towards get ting the Ph.D . Tom Deeke put up w ith my countless interruptions and distractions at Hughes. He was a sounding board for m any initial ideas. George K ateyiannis is a friend who spent m any lunches w ith me discussing technical subjects such as j com puter and telephone networks, economics, pricing models, and nonlinear pro gramming. I am grateful for his help. I would also like to thank a few instructors from UCI who challenged me to succeed in those early years, namely Norm Jacob son, Prof. K athleen Gregory-Huddleston, and Prof. Dennis Volper. I have been blessed w ith a very loving and supportive family who has encouraged me in w hatever I set out to accomplish. In particular, I would like to thank my parents, Dino and Rose Marie, who have given me more than I could have ever asked for throughout my entire life. I hope th at I can bring as much joy and happiness to their lives as they have brought to mine. I also wish to thank m y grandparents whose traditional values taught me what to appreciate in life. Finally, I would like to thank my wife M aureen for her unceasing love, support, and encouragem ent during my graduate studies. She has m ade countless sacrifices to insure my success in graduate school and has spent m any nights home alone on my account. Her technical competence and numerous reviews assisted me in clarifying m any concepts presented in this dissertation. My finishing the program is as much her accom plishm ent as it is mine. I am grateful th a t I will have an opportunity to help com pensate her for these losses in the m any years th a t follow. Contents A ck n o w led g m en ts ii L ist O f T ables vii L ist O f F igu res ix A b stra ct x 1 In tro d u ctio n 1 2 R ela te d W ork 4 2.1 Integrated Com puter Networks .................................................................... 5 2.1.1 Gateway Queueing D iscip lin es......................................................... 6 2.1.2 Packet Discarding S tra te g ie s............................................................. 8 2.1.3 Admission Control P o licies................................................................ 9 2.1.4 Pricing in Com puter S y s t e m s ......................................................... 10 2.2 Pricing Polices and Resource A llocation...................................................... 12 2.2.1 Flat Pricing w ith Random R a tio n in g ........................................... 14 2.2.2 Spot P ric in g ............................................................................................ 15 2.2.3 Peak Load P r i c i n g .............................................................................. 16 2.2.4 Priority Service P ric in g ....................................................................... 16 2.2.5 Comparison of Priority Service to O ther Approaches . . . . 17 2.2.6 A Comparison of Telephone and Com puter Communications Networks .............................................................................................. 18 3 M o tiv a tio n 20 i I 4 P ric in g as a Form o f In cen tiv e 25! 4.1 Problem Statem ent and System M o d e ls 27 J 4.2 A bstract F o rm u latio n ....................................................................................... 281 4.3 E x a m p le ................................................................................................................. 311 4.3.1 Service Discipline and Pricing Policies ........................................ 32 4.3.2 Definition of VavpiiC ation $ ...................................................................... 33, F 4.3.3 Applying the A bstract F o rm u la tio n ............................................... 36 4.3.4 Simulation Details .............................................................................. 37 4.3.5 Network Configurations ................................................................... 38 4.3.6 R e s u lts ...................................................................................................... 44 4.4 C onclusion............................................................................................................. 52 5 In terp lay B etw een P rice and C o n g estio n 54 5.1 Problem Statem ent and System M o d e l ..................................................... 55 5.2 Simulation E n v iro n m e n t................................................................................. 57 5.3 D ata and Analysis ............................................................................................ 59 5.4 Benefit A n aly sis.................................................................................................. 64 5.5 C onclusion............................................................................................................. 66 6 In creased U tility T h rou gh C harging 67 6.1 Problem Statem ent and System M o d e ls..................................................... 68 6.2 Reservation Oriented Network M o d e l......................................................... 69 6.2.1 Queueing M o d e ls ................................................................................. 71 6.2.1.1 Evaluation and Analysis of Queueing Models . . . 76 6.2.2 Sim ulation M o d e ls .............................................................................. 86 6.2.2.1 Sim ulation D e t a i l s ............................................................. 90 6.2.2.2 Evaluation and Analysis of Sim ulation Models . . . 90 6.3 Reservationless Network M o d e l ................................................................... 113 6.3.1 Evaluation of the Reservationless Network M o d e l ................... 114 6.4 C onclusion........................................................................................... 121 7 S u m m ary and E x ten sio n s 122 7.1 Significance of Work ........................................................................................ 122 7.2 Practical Perspective of W o r k ....................................................................... 124 7.3 Future W o rk .......................................................................................................... 127 7.4 C onclusion............................................................................................................. 128 R eferen ce L ist 130 vi L ist O f T a b les 3.1 Param eters of S erv ice....................................................................................... 23 4.1 A pplication C h aracteristics............................................................................. 34 4.2 Configuration 1 on Network Topology A .................................................... 40 4.3 Configuration 2 on Network Topology A .................................................... 40 4.4 Configuration 3 on Network Topology A .................................................... 41 4.5 Configuration 4 on Network Topology A .................................................... 41 4.6 Configuration 5 on Network Topology B .................................................... 42 4.7 Configuration 6 on Network Topology C .................................................... 42 4.8 Configuration 7 on Network Topology C .................................................... 43 4.9 Aggregate Traffic Characteristics ............................................................... 45 4.10 Sim ulation Results for Configuration 1........................................................ 45 4.11 Sim ulation Results for Configuration 2........................................................ 45 4.12 Sim ulation Results for Configuration 3........................................................ 46 4.13 Sim ulation Results for Configuration 4........................................................ 46 4.14 Sim ulation Results for Configuration 5........................................................ 46 4.15 Simulation Results for Configuration 6........................................................ 47 4.16 Sim ulation Results for Configuration 7........................................................ 47 4.17 Service Discipline D istribution for Configuration 1.................................. 52 5.1 Telnet Normalized Network O perating Cost A n a ly s is ......................... 59 5.2 Voice Normalized Network O perating Cost A n a ly s is ............................ 60 5.3 F T P Normalized Network O perating Cost A n a ly s is ............................ 60 5.4 Em ail Normalized Network O perating Cost A nalysis............................ 60 5.5 U tility A n a ly s is .................................................................................................. 63 5.6 Price Range Benefit A nalysis......................................................................... 65 6.1 Predictive analysis w ith p j = 0.95, b = 0.38, and w = 0.1.................... 85 6.2 Predictive analysis w ith pf = 0.2, 6 = 0.38, and w — 1.......................... 85 6.3 Predictive analysis w ith p f = 0.8, b = 0.9, and w — 1............................ 85 6.4 Predictive analysis w ith p / = 1, b = 0.999, and w = 10......................... 91 6.5 Three Class Simulation Traffic Configurations.......................................... 91 6.6 Three Class Simulation Link Speeds............................................................. 91 6.7 Overview of Reservation O riented M ulticlass Simulation D ata. . . . 96 vii 6.8 Conf 1, 40 Mbps Link, w = 0.5, Naive Model w ith giveup......... 97 6.9 Conf 1, 40 Mbps Link, w = 0.5, Predictive Model w ith giveup. . . . 97 6.10 Conf 1, 40 Mbps Link, w = 0.5, Naive Model w ith nogiveup.... 98 6.11 Conf 1, 40 Mbps Link, w = 0.5, Predictive Model w ith nogiveup. . . 98 6.12 Conf 1, 40 M bps Link, w = 1, Naive Model w ith giveup.................. 99 6.13 Conf 1, 40 Mbps Link, w = 1, Predictive Model w ith giveup......... 99 6.14 Conf 1, 40 Mbps Link, w = 1, Naive Model w ith nogiveup............. 100 6.15 Conf 1, 40 Mbps Link, w = 1, Predictive Model w ith nogiveup. . . . 100 6.16 Conf 1, 40 Mbps Link, w — 5, Naive Model w ith giveup.................. 101 6.17 Conf 1, 40 Mbps Link, w = 5, Predictive Model with giveup......... 101 6.18 Conf 1, 40 Mbps Link, w = 5, Naive Model w ith nogiveup............. 102 6.19 Conf 1, 40 Mbps Link, w = 5, Predictive Model w ith nogiveup. . . . 102 6.20 Conf 1, 40 Mbps Link, w = 10, Naive Model w ith giveup...................... 103 6.21 Conf 1, 40 Mbps Link, w = 10, Predictive Model w ith giveup. . . . 103 6.22 Conf 1, 40 Mbps Link, w — 10, Naive Model w ith nogiveup...................... 104 6.23 Conf 1, 40 Mbps Link, w = 10, Predictive Model w ith nogiveup. . . 104 6.24 Conf 2, 55 Mbps Link, w = 0.5, Naive Model w ith giveup......... 105 6.25 Conf 2, 55 Mbps Link, w = 0.5, Predictive Model w ith giveup. . . . 105 6.26 Conf 2, 55 Mbps Link, w = 0.5, Naive Model w ith nogiveup.... 106 6.27 Conf 2, 55 Mbps Link, w = 0.5, Predictive Model w ith nogiveup. . . 106 6.28 Conf 2, 55 Mbps Link, w — 1, Naive Model w ith giveup.................. 107 ! 6.29 Conf 2, 55 Mbps Link, w — 1, Predictive Model w ith giveup......... 107 6.30 Conf 2, 55 Mbps Link, w = 1, Naive Model with nogiveup............. 108 6.31 Conf 2, 55 Mbps Link, w — 1, Predictive Model w ith nogiveup. . . . 108 6.32 Conf 2, 55 Mbps Link, w = 5, Naive Model w ith giveup.................. 109 6.33 Conf 2, 55 Mbps Link, w = 5, Predictive Model w ith giveup......... 109 6.34 Conf 2, 55 Mbps Link, w = 5, Naive Model w ith nogiveup.............. 110 6.35 Conf 2, 55 Mbps Link, w = 5, Predictive Model w ith nogiveup. . . . 110 6.36 Conf 2, 55 Mbps Link, w — 10, Naive Model w ith giveup...................... I l l 6.37 Conf 2, 55 Mbps Link, w = 10, Predictive Model w ith giveup. . . . I l l 6.38 Conf 2, 55 Mbps Link, w = 10, Naive Model w ith nogiveup...................... 112 6.39 Conf 2, 55 Mbps Link, w = 10, Predictive Model w ith nogiveup. . . 112 6.40 Increased U tility Table for Conf 1 on Network Topology.A ................. 115 6.41 Increased U tility Table for Conf 2 on Network Topology.A ................. 116 6.42 Increased U tility Table for Conf 3 on Network Topology A ................. 116 6.43 Increased U tility Table for Conf 4 on Network Topology.A ................. 117 6.44 Increased U tility Table for Conf 5 on Network Topology B ................. 117 6.45 Increased U tility Table for Conf 6 on Network Topology C ................. 118 6.46 Increased U tility Table for Conf 7 on Network Topology C................ 118 ; viii: L ist O f F ig u r e s 4.1 Network Topology A ........................................................................................ 39 4.2 Network Topology B ........................................................................................ 39 4.3 Network Topology C ........................................................................................ 39 4.4 Acceptable Price Range for Configuration 1............................................... 51 4.5 A doptable Price Range for Configuration 1................................................ 51 5.1 Telnet Price Curve and Average U tility Function ................................ 61 5.2 Voice Price Curve and Average U tility F u n c tio n .................................... 61 5.3 F T P Price Curve and Average U tility F u n c t i o n .................................... 62 5.4 Em ail Price Curve and Average U tility F u n c tio n ................................... 62 6.1 Naive Model U tility per Second w ith pQ — 0.975....................................... 78 6.2 Naive Model U tility per Second w ith pa — 0.933....................................... 78 6.3 Naive Model U tility per Second w ith p0 = 0.650....................................... 79 Abstract In order to m eet the varied quality-of-service requirem ents of network appli cations (such as file-transfer, video, and voice), future packet-switched com puter com m unication networks will offer m ultiple service classes. Such m ulticlass network service disciplines, if used properly, utilize network resources more efficiently than single-class service disciplines. W hether or not these m ultiple service classes are used properly depends on th e incentives individual users encounter when using the network. Thus, the issue of user incentives m ust be considered in the design and im plem entation of internet protocols. The two m ost im portant forms of user in centives in internets are network perform ance and pricing policy (where prices may take different forms, e.g. real money, funny money, and adm inistrative). We study the role of pricing policies in m ultiple service class networks. We first argue th a t some form of service-class sensitive pricing is required in order for any m ulticlass service discipline to have the desired effect. Borrowing heavily from the Nash im plem entation paradigm in economics, we then present an abstract form ula tion of service disciplines and pricing policies. This form ulation allows us to clearly describe the interplay between service disciplines and pricing policies. Effective m ul ticlass service disciplines allow networks to focus resources on perform ance sensitive applications. Effective pricing policies can distribute the benefits of m ultiple service classes to all users, rather than having these benefits rem ain exclusively w ith the users of perform ance sensitive applications. We illustrate some of these concepts i through sim ulation and find th a t it is possible to set prices such th at users of ev-| ery application type are more satisfied w ith the combined cost and perform ance of a network w ith service-class-sensitive prices. For some application types the p e r-, formance penalty received for requesting a less-than-optim al service class is offset ! by the reduced price of the service. For the other application types the m o n etary ! x penalty incurred by using the m ore expensive, higher-quality, service classes is offset by th e improved perform ance they receive. We next analyze the effect of a simple usage sensitive pricing scheme on total happiness, as com pared to a network w ithout a charging policy. Economists have long argued th a t any scarce resource shared by a large group of self-interested users, requires some form of usage-sensitive incentive structure to discourage overuse. In this analysis we do not compare two distinct pricing schemes as much as we com pare charging verses not charging. We construct and assess utility in two types of network models: reservation oriented and reservationless. In the former model we examine charging in the context of admission control where user dem and is a function of th e price paid for network service. The charge discourages a fraction of the population w ith lower benefits so th a t users w ith higher benefits experience less delay in obtaining network service, thereby, experiencing increased utility. In the latter model offered load is held constant and the d ata pipe size is varied to reflect different levels of network congestion. In this model, the charge encourages users to select the priority m ost appropriate to their application w ithout a constant revenue condition. In both models, the objective of the charge is to increase to tal utility for the heterogeneous user population at large. To m y wife, parents, grandparents, and brothers. Every thought which genius and piety throw into the world alters the world. — Ralph Waldo Em erson Chapter 1 Introduction The last thing one knows when constructing a work is what to put first. — Blaise Pascal Recent research on com puter networks has been concerned almost exclusively w ith th e hardw are, software, and protocol standards needed to achieve b etter n et work perform ance. Today’s com puter networks link thousands of institutions and have become an indispensable p art of the academic and industrial com m unication infrastructure. These networks support a wide variety of applications, including ter m inal connections, file transfers, electronic mail, X-server connections, voice, and video. Furtherm ore, significantly faster and more sophisticated networks are cur rently being designed and prototyped; it is expected th a t these networks will spark a whole new generation of applications. However, such technical progress is not the only im portant issue affecting net work perform ance. Network perform ance, at least from the perspective of end users (applications), is not completely determ ined by the technical characteristics of the network. Network perform ance is also a function of the offered load. The aggregate traffic load on a network is th e result of m any users’ individual decisions about ■ w hether and how to use the network, and these decisions are affected by the in centives these users encounter when using the network. We define incentives as som ething th a t stim ulates or m otivates a user to take action. This dissertation represents an initial effort to grapple w ith user incentives in m ultiple service class networks. We restrict our focus to one particular aspect of user incentives; the intertw ining of pricing policies, which produce m onetary1 incentives, and m ulticlass service disciplines, which produce perform ance incentives. We study fundam ental microeconomic issues involved in the interplay between pricing policies and m ulticlass service disciplines and lay the groundwork for future research. The goals of the present research are to: a) dem onstrate through sim ulation th a t user incentive policies such as pricing are necessary in m ultiple service class networks to provide the highest possible utility to end users, b) evaluate through analytical and sim ulation models the design of user incentive policies under a wide range of exam ple networks, and c) analyze th e effect th a t incorporating a charge has on user satisfaction. We discuss related work in C hapter 2 w ith a broad discussion of technical issues pertaining to m ultiple service class com puter com m unications networks, as well as fundam ental microeconomic principles related to pricing policies and resource allo cation. We will use these concepts throughout the dissertation. In C hapter 3, we m otivate th e proposed research direction. We review certain technical and in stitu tional characteristics of the current Internet, and then discuss how these are likely to change in the design and development of future networks. We believe th a t these predicted changes will bring the interaction between pricing and m ulticlass service disciplines to the forefront of the networking com m unity’s technical agenda. We present our models and analyses in the subsequent three chapters. In C hapter 4 we present an abstract form ulation th a t allows us to articulate precisely the roles of ser vice disciplines and pricing policies and then discuss how they interact. We consider a network w ith a simple two-priority service discipline and several different applica- I tion types (electronic m ail, packetized voice, file transfer, and interactive term inal 1 Pricing can refer to forms of incentives other than money; for instance, one can price service in terms of administrative incentives such as quotas or logs. W hile our framework could be generalized to these other forms of pricing, for the sake of sim plicity we will refer only to monetary incentives j in this paper. 1 I 2! __I connection) running over standard transport-layer protocols. C hapter 5 examines the interaction between network congestion and price. We analyze variations in to tal utility resulting from network dynamics caused by changes in the num ber of users and price. C hapter 6 examines w hether using a simple usage sensitive pricing policy can increase a user’s utility. We first study u tility in a free network and then incorporate a charge and study the subsequent effects on user utility. We per form this analysis in th e context of two network models. T he first model consists of reservation-oriented single and m ultiple class networks, while the second model consists of m ultiple class, reservationless, networks. In the first m odel we im ple m ent an elastic dem and function where offered load is a function of price. In the second m odel, we hold offered load constant and vary the d ata pipe size. Finally, in C hapter 7 we sum m arize the contributions and provide a practical perspective on our work. We also present directions for future research. Chapter 2 Related Work The old order changeth, yielding place to new. — Alfred Lord Tennyson In this chapter we explore technical and economic issues related to the integra tion of m ultiple network technologies. M any aspects of perform ance incentives are discussed in Section 2.1. We survey gateway queueing disciplines, packet discard policies, admission control policies and existing com puter network pricing studies for integrated networks. In Section 2.2 we present several economic views related to resource allocation and price theory. Pricing models studied in this section m otivate th e development of the m onetary incentive policy used in our sim ulation models. Resource allocation under price structures such as flat pricing, spot pricing, peak load pricing, and priority pricing is examined. 2.1 Integrated Computer Networks U ntil recently, much of the published literature on com m unications research has focused on designing networks for specific technologies, e.g. public telephone net works, d ata networks, cable TV networks, etc. Network designers face great chal lenges when expanding networks to integrate new technologies. Integration is dif ficult because of both hardw are and protocol restrictions. For exam ple, th e exist ing telephone network was designed for low bandw idth fixed rate traffic. It does not efficiently support high bandw idth bursty file transfer or video traffic. A re cent th ru st in studying m ultim edia com m unications and high speed networks has helped instigate research in integrated com puter com m unications networks. N et work architectures th at integrate packetized voice, video, images and d ata are being developed[3, 15, 25, 31, 46, 53], This integration effort has exposed inadequacies in current algorithm s and poses new challenges to the design of real-tim e applications, m ultiple service classes, and new congestion and flow control policies. Com puter network integration is m otivated by several factors. F irst, integrated networks are economically attractive. It can be cheaper and m ore efficient to de sign one integrated network than to develop m any dedicated networks[13, 66, 69]. Second, packet switching has m atured over the past tw enty years and is capable of supporting a wider range of applications [27, 57, 63]. Third, the arrival of high speed networks provided the technology to transm it d ata at speeds th a t were unim agined a decade ago [1, 60, 69]. Increased bandw idth coupled w ith the flexibility of sta tistical m ultiplexing gives m odern networks the capability to support m any diverse user-classes simultaneously. Finally, Integrated Services Digital Network (ISDN) pro tocols and systems provide relatively narrow band voice and d ata services to m any users [39, 63, 68]. ISDN has increased user interest in integrated networks. But by itself ISDN does not satisfy resource intensive com puter com m unications users j because of its low peak bandw idth. In subsequent sections we discuss m any technical issues commonly found in com puter network com ponents th a t are relevant to our study. We evaluate gateway queueing disciplines, packet discard policies, admission control policies and pricing! j studies in com puter networks. Each strategy or policy is designed to m anipulate; ^ th e m anner in which traffic flows, either w ithin the network or into the network. ; 2.1.1 G a tew a y Q u eu ein g D isc ip lin e s Gateways (interm ediate systems) are prim arily concerned w ith two issues: service discipline and buffer access control discipline. Gateways can satisfy both disciplines by using priority schemes, which merely shuffle the m anner in which resources are allocated. Packet priorities can be selected according to m any factors: tim e spent in th e network, tim e spent in the queue, fixed priority based on application type, willingness to pay, adm inistrative controls, distance from destination, or a variety of other fixed and dynam ic approaches. This section presents several prioritized gateway service disciplines. We generalize the notion of gateway service to include routing. The investigations considered here consist prim arily of sim ulation and m athem atical analysis. A discussion of buffer access control policies in integrated networks can be found in Section 2.1.2. Several approaches th a t queue packets according to static priority have been suggested [17, 32, 37]. Packets w ithin a priority class are serviced according to a First-Com e-First-Serve (FCFS) discipline. Although easy to im plem ent, static priority schemes suffer from issues of fairness. High priority traffic can monopolize j th e output channel for long periods of tim e, thereby degrading the performance! of lower priority traffic. W hen service priorities are fixed, there is no guaranteed m axim um delay for lower priority service classes; assuming queue sizes are fixed, the highest priority service class will always have an absolute upper bound on service delay (but m ay experience dropped packets). Preventing higher priority traffic from monopolizing the output channel can b e ! accom plished by dynam ically adjusting the priority in real-tim e. S tatic priorities can be increm ented as queue waiting tim es increase as shown in [5, 32, 36]. Dynam ic schemes can also decrease packet priorities w ith time[4]. We briefly survey several dynam ic priority schemes th a t appear in the lite ra tu re .! Klienrock [32] proposes a scheme where traffic is grouped into classes w ith each class! having different service requirem ents. Packet priorities begin at zero upon arrival | and increase w ith tim e at a rate th a t is a function of the service class. The num ber of j j service classes and rates of increase can be chosen to m atch a variety of perform ance j j requirem ents. Lin and Silvester [37] survey a num ber of gateway priority service, i.e. Head- of-Line (HOL), and packet discard policies. They provide a m athem atical analysis of several buffer sharing strategies. Complete buffer sharing allows gateway buffers to be shared equally among all user classes. Higher priority classes receive service before lower priority classes. If the push-out technology is used, lower priority packets are replaced by arriving higher priority packets when the queue reaches capacity. U nder partial buffer sharing all classes of traffic are not allowed equal access to gateway buffers. W hen the num ber of buffers in all classes exceed a threshold, lower priority classes are denied buffer access. In both buffer sharing strategies, traffic w ithin classes is serviced FCFS. T he final approach, complete buffer partitioning, m aintains a separate queue for each user class. Subsequent packets arriving at a full queue are discarded. Their analysis of these schemes concludes th a t significant im provem ents can be achieved by higher priority traffic w ith little im pact on the perform ance of lower priority traffic. Lim et al. [36] provide an extensive m athem atical analysis of Head-of-Line with Priority Jum ps (H O L-PJ) for m ulti class packet switching. Their approach utilizes a system of queues, one for each service class. Packets receive service FCFS w ithin each queue beginning at the highest priority queue. Packets in a given queue have a m axim um waiting tim e after which they jum p to the end of th e next higher queue. Thus, the overall m axim um waiting tim e for a packet is well defined in all cases where finite queue lengths are assumed. The scheme has been shown to be fair through its ability to m eet any average delay requirem ent for each service class. Im plem entation is relatively straightforw ard requiring only a local clock and a list of packet arrival tim es for each service queue. O ther dynam ic priority schemes adjust priority based on the real-tim e offered load of various user classes. These policies are typically based on system configurable threshold param eters. Threshold based queuing policies such as M inim um Laxity Threshold (MLT) and Queue Length Threshold (QLT) are studied in [3, 14, 34]. These policies control the gateway service discipline for real-tim e and non-real-tim e traffic by giving real-tim e traffic priority until the offered load exceeds the threshold at which tim e non-real-tim e traffic is given priority. These schemes attem p t to prevent real-tim e traffic from monopolizing gateway resources thus insuring fairness j for non-real-tim e traffic. Num erical models, corroborated by sim ulation discussed in [34], show equivalence between these two approaches, th a t is, it is possible to set traffic threshold param eters such th at the MLT policy can be approxim ated by the QLT discipline. The QLT discipline is preferred because of its straightforw ard im plem entation strategy. Fair Queueing, our final gateway service discipline, removes incentives from indi vidual sources th a t wish to exceed their allocation of network resources[19, 47, 51]. Gateways m aintain separate packet queues for each flow or user class. Queues are serviced round-robin, preventing sources from arbitrarily getting m ore th an their fa ir share of gateway resources. Priority can be im plem ented in conjunction w ith this approach by modifying the round-robin service discipline to give larger shares to higher priority user classes (weighted fa ir queueing [51]). 2 .1 .2 P a ck et D isca rd in g S tra te g ies Integrated networks can disrupt traffic of some user classes. For exam ple, if voice traffic is given priority over data, the transm ission link can be monopolized by voice packets whenever its offered load reaches the capacity of the outp u t channel. Yin et al. [72] describe an approach th at discards a small percentage of voice packets when the voice offered load exceeds a threshold. They present a m athem atical analysis as well as prelim inary sim ulation results showing th at the m ean waiting tim e for data can be significantly reduced by discarding a small percentage of voice packets. The technique presented could be easily extended to m eet the perform ance criteria for a wide variety of applications under heavily loaded conditions. T he drop rate is a function of the num ber of buffers at interm ediate nodes. The num ber of output buffers m ust be kept small to reduce delay. Chen[13] shows th at delay becomes exceedingly high when heavy load is placed on interm ediate systems w ith very large buffers. Voice applications have a strict one-way delay bound ranging between 100-600 ms [13],1 T he public telephone network specifies an absolute delay bound of 600 ms [7]. As the delay bound increases the ability to conduct a coherent conversation diminishes. 1Other authors such as in [46, 73] specify a much tighter delay bound, between 50-200 ms. j ___________________________________________________________________________________________ ?j In [73], Yuan et al. study the perform ance characteristics of two voice packet drop policies. The first policy is called instant drop. Using this policy, the incoming packet is dropped when the queue is full. Due to th e transm ission characteristics of sending nodes, this policy m ay cause an individual node to experience an unusually high drop rate even though the system drop rate m ay be low. They refer to the second policy as random drop. U nder this approach, when a packet arrives and the queue is full, a random packet from the queue is discarded. T he random drop policy is shown to be fairer resulting in a lower variance in the drop rate (drops are more evenly spread across all talk spurts). However, as described by M ankin [41] this approach is not w ithout its drawbacks. Since packet losses are typically signals to end systems to reduce the transm ission rate, the random drop policy m ay deliver signals to th e wrong sender, thereby not slowing th e packet arrival rate by nodes causing congestion. Random drop could result in a greater num ber of connections experiencing dropped packets. Bae and P etr [3, 53] discuss discarding voice and video packets on a priority basis to m inim ize degradation of the regenerated signal at the user level. Some packets are higher priority th an others by virtue of adm inistrative policies, characteristics of the data, price paid by th e user, or network investm ent. Each packet contains a priority field. For example, packets m ost likely to contain background noise are discarded before probable active voice packets. A broad discussion of regeneration! and encoding techniques th a t minimize degradation of the user signal in packet! switched com puter networks can also be found in [13, 26, 31, 44, 62]. j 2 .1 .3 A d m issio n C on trol P o licies In C hapter 6 we discuss our reservation oriented network models. Reservation ori ented networks provide a mechanism for m aintaining Quality o f Service (QoS) com-, m itm ents required for real-tim e applications such as voice and video. Admission; control is an im portant com ponent in m aintaining QoS com m itm ents. T he admis-j sion control m odule rejects a new service request when it cannot simultaneously) I uphold its existing QoS com m itm ents in conjunction w ith the new one. AdmissionJ control is problem atic because real-tim e applications are typically bursty, thereby,1 m aking it difficult to accurately characterize traffic patterns. A ccurate traffic char acterization is necessary because simply reserving bandw idth at each application’s peak rate would be inefficient. N aturally, the bandw idth allocation function influ ences application level perform ance experienced by end-users. T he potential im pact on application perform ance justifies the intense debate over admission control poli cies. In this section we describe three such policies. In [30], Hym an et al. develop a joint scheduling and adm ission control mech anism for guaranteed QoS networks. Their scheme uses linear program m ing tech niques to define the scheduling lim its of their admission control policy, which they refer to as the schedulable region. The scheduler dynam ically m onitors the flow of traffic through the switch. This inform ation is used to calculate th e schedulable region used by the admission control module. They provide num erical calculations for a single M A G NET II switching node carrying two classes of real-tim e traffic. Ferrari and Verma [25] propose a scheme for establishing real-tim e channels w ith determ inistic and statistical delay bounds. Their scheme utilizes a slightly i modified earliest due date control policy. In addition to determ inistic and statistical traffic, their scheme also contains a th ird class used by all other types of traffic. For efficiency reasons, each switch m aintains a separate queue for the three traffic types. They show th a t service guarantees can be m aintained even in worse case situations. Their analytical results are extended through simulation. Our final scheme capable of supporting real-tim e perform ance guarantees was developed by Parekh [51] and extended by Clark et al. in [16]. Parekh has proven th a t for an arbitrary network topology under certain conditions the weighted fair queueing scheme, originally proposed in [19], can deliver guaranteed quality of ser vice. This analysis specifies an upper bound for the queueing delay in th e network, given th a t no link in th e p ath is over com m itted, i.e. th a t the level of reserved bandw idth for each link does not exceed the link capacity. Using this property, worst case delays and rates can be guaranteed for every user in th e network. 2 .1 .4 P ricin g in C o m p u ter S y stem s Parris et al. [52] address the issue of pricing in com puter networks, b u t their focus is rath er different from th a t of this dissertation. They consider a reservation-oriented^ I i I i o i service discipline similar to the model we propose in C hapter 6. However, their m odel does not explicitly deal w ith user incentives, rath er it considers the constraints im posed by finite budgets. Their study addresses pricing in the context of revenue generation b u t is based on an illogical assum ption th a t users always exhaust their budgets even if they can only afford extrem ely short service requests, i.e. each user has a finite budget and will purchase the m axim al am ount of network service they can afford. T he issue of user incentives is im portant because it provides a basis on which to im plem ent a graduated pricing structure, which can b ette r serve the com m unity at large [70]. The issue of pricing in com puter systems is studied by Ferguson [23]. He broadly applies microeconomic principles to three types of com puter systems: load balanc ing, flow control in virtual circuit networks, and d ata m anagem ent. This research evaluates an optim al allocation for com puter resources by trying to m inim ize de lay and maxim ize throughput based on finite user budgets. His work does not address user incentives and does not study the issue of pricing in integrated com puter com m unications networks. We develop a notion of to tal (system ) u tility t h a t : i is a function of price, not found in his work. O ther research em phasizing similar objectives can be found in [10, 29]. Sanders [59] addresses an incentive com patible flow control algorithm for rate based allocation in com puter networks. Her study of delay and throughput is some w hat sim ilar to th a t of Ferguson except th a t she defines specific u tility functions and introduces an incentive com patible pricing structure where lower prices are offered for lower levels of service. This model embodies a myopic assum ption where users attem p t to m axim ize their objective function but do not attem p t to predict the fu ture. Her treatm en t of user incentives in the context of flow control is m ore narrow than our treatm en t of utility in the m ultiple service class, end-user environm ent as presented in C hapter 6. t Finally, R utenburg et al. [58] study charging policies and m inim um-expected-J cost routing in internets w ith packet loss. They construct an internetw ork model consisting of autonom ous domains (A D’s) and develop algorithm s th a t m inim ize > the individual dom ain’s expenses as well as global resource consum ption. Their j charging policy assigns fa ir wages to individual domains for successful delivery and ■ fa ir penalties for packet loss. They establish fair prices such th a t the expected return for th e network is zero, allowing each AD to break even in the long run. They also introduce accounting procedures for im plem enting their proposed charging policy. In this section we have reviewed some of th e recent literatu re addressing pricing in com puter systems and com puter com m unications networks. M uch of this work represented early attem pts analyzing resource allocation exclusively in th e presence of budget constraints. We have also surveyed a num ber of packet handling policies proposed for high speed integrated networks. These policies are necessary to m eet the range of service requirem ents presented by real-tim e and non-real-tim e applications. Considerations such as low nodal pro cessing and efficient resource allocation are vital to the effectiveness of high speed protocols and to insure good performance. However, as we described in Section 1, hardw are, software, and protocol standards are not the only factor influencing n et work perform ance. N ext, we describe a num ber of pricing models th a t provide user incentives to encourage efficient allocation of scarce resources. We argue th a t an alternate incentive is required to provide a balance against perform ance incentives available in high speed integrated networks. We will use price as a mechanism for increasing to tal u tility in com puter networks. 2.2 Pricing Polices and Resource Allocation Early economists m ade a distinction between th e price and the value of a commodity. C urrent economic theory states th a t commodities are traded based on im plicit value. The m arket price of a com m odity is an estim ation of its value in term s of opportunity cost. Prices are needed to make exchanging goods between two economic agents easier. Price is a ratio of quantities specifying the am ount of good x th a t m ust be given up to obtain a unit of good y. The theory of value concerns the determ inants j of a com m odity’s worth or im portance. Study of the determ inants of value is closely associated w ith study of optim al allocation of scarce resources[50]. M any proposed rate structures apply to industries th a t offer nonstorable goods (i.e. telephone, electric power, transportation, and com puter network) [9, 11, 12, J 20, 21, 42, 70]. Such industries producing are typically capital intensive, have fixed i j 12 f capacity, and are subject to peak loads. The objective for creating rate structures h as been to improve satisfaction of a wide range of social objectives such as reliability jof supply, cost m inim ization, custom er benefit m axim ization, and supplier profit ■maximization. We exam ine how rate structures affect resource allocation and social welfare. If a large num ber of individuals seeking to m axim ize personal welfare are placed ■ in a perfectly com petitive m arket,2 economic theory indicates th a t individuals will adjust production levels and exchange goods until all participants have identical m arginal rates of substitution on each good [65].3 Prior to equilibrium , exchanges raise individuals to higher indifference curves4 because all participants benefit from such trades. Prices provide a common denom inator among individuals by defining the relative value each places on a particular alternative. See [33, 38, 50] for a more detailed explanation of these issues. Consistent w ith th e theory of a m arket in equilibrium , where suppliers and dem anders are content w ith the m arket outcom e, we define a strategic equilibrium form alized by Nash [49]. In Nash equilibrium, no single agent can unilaterally take an action th a t improves its allocation of resources; therefore, no agent has an incentive to deviate from its current selection. A pair of strategies, (a*, b*), is defined to be in Nash equilibrium if a* represents A ’s best move when B plays b* and b* represents B 's best move when A plays a*. One player cannot benefit from knowing th a t the other will never deviate from this strategic equilibrium , which is not the case in nonequilibrium strategies. T he concept of Nash Equilibrium is extrem ely im portant to our study because we are prim arily concerned w ith th e user incentive issues in m ultiple service class com puter com m unications networks. We make use of this definition in C hapters 4 and 6 where we define our models and introduce our pricing policy. We formalize a m odel showing th a t th e selfish Nash equilibrium results in service requests by each [ 2In a perfectly com petitive market, economic agents have complete knowledge of the system . No one individual can significantly influence the behavior of others. 3The marginal rate of substitution is defined to be the rate at which an individual is willing to , trade one good for another while remaining equally well off. I 4An indifference curve specifies a plot of an individual’s utility function showing those alternate ] bundles of goods from which the individual derives equal levels of welfare. j 13 application type th a t m axim ize the overall level of satisfaction in th e network. A deeper discussion of Nash Equilibrium can be found in [33, 43, 50]. An allocation of resources th a t m axim izes m utually beneficial exchanges is called Pareto Efficient [38, 50]. More precisely, a P areto efficient allocation of resources occurs when all exchanges have been m ade such th a t no one agent is m ade b e tter off at the expense of another. Once Pareto optim ality is realized, no ubiquitous gains are possible because all exchanges th a t are m utually beneficial to all trading parties have been exercised. It should be noted th a t there may exist m any P areto efficient allocations since each trading party m ay consider a set of alternatives equivalent.5 In Sections 2.2.1 - 2.2.4 we evaluate and com pare the P areto efficient resource allocations under several pricing policies. T he m erits and pitfalls of each pricing policy are considered. Section 2.2.5 compares the priority pricing policy to other pricing policies introduced in this section. Section 2.2.6 discusses pricing in the telephone industry and describes how pricing in this industry differs from pricing in integrated high speed com puter networks. 2.2.1 F la t P ricin g w ith R a n d o m R a tio n in g We use flat pricing as our base pricing scheme for com parison to other pricing policies. A flat pricing scheme assesses a single charge to all custom ers. It is fa ir in the sense th a t a uniform cost is attrib u ted to all custom ers and the allocation of J resources is First-Com e-First-Serve (FCFS). However, this pricing policy often leads to idle capacity during slack periods and arb itrary allocation of scarce resources during peak periods. The weakness of this approach arises from its inability to categorize service requests into discrete priority classes. Obviously, when resource requests exceed capacity, additional service requests cannot be accepted. Service requests am ong stochastic processes cause service degradation th a t m ust be spread proportionately across all customers; therefore, when resource requests have differing priorities, this scheme inherently fails to m axim ize social welfare among all user classes. 5Pareto efficiency also depends on the initial resource endowments. 2.2.2 Spot P ricin g Spot pricing is not based on predeterm ined static ra te s[ll, 12, 70]. R ather, spot pricing is based on product generation costs th a t are a function of instantaneous dem and. Spot pricing reflects the short-run m arginal cost to deliver th e good or service. Theoretically, prices are updated in continuous tim e giving custom ers im m ediate feedback of current rates; however, since the cost required to com m unicate th e prices to consumers is nonzero, spot prices are usually reported to consumers at fixed intervals. For exam ple, Caram anis [11] propose using a three tier reporting scheme in th e electric industry where prices are com m unicated to consumers at intervals of 5 m inutes, 24 hours and time-of-use. The 5 m inute interval reflects spot price updates subject to highly dynam ic conditions, such as, peak load, outages, and weather variations. T he 24 hour reporting interval update reflects short term predictable events, such as, known outages, daily w eather forecasts, and installation of new equipm ent. Finally, the time-of-use spot price is established according to long term predictable events like facility enhancem ents. U nder realistic im plem entations, all users m ay not receive price updates according to a united reporting schedule. Large industrial users m ay receive 5 m inute updates while smaller household users m ay receive only 24 hour updates. Industrial users typically have a greater im pact on aggregate dem and and possess equipm ent capable of autom atic regulation th a t can react to frequent changes in. spot prices. As described by Chao[12], spot pricing is Pareto superior to any other pricing policy. T h at is, optim al spot prices always achieve a higher social welfare over any other pricing scheme. T he following factors contribute to optim al spot price Pareto superiority. Spot m arkets 1) have closed loop feedback control, 2) have a lower I l level of involuntary blackouts (approaching zero as th e percentage of spot m a rk e t; custom ers increase), 3) have lowest level of optim al to tal capacity, 4) have lowest j custom er cost and highest provider profits (unless regulation forces redistribution), and 5) give the controller m ore degrees of freedom th an any other pricing scheme (the controller can always set prices equal to predeterm ined fixed rate and achieve ^ .sam e social welfare as fixed price scheme). Lim ited applications of spot pricing in th e electric industry have been im plem ented in the U.S. and abroad[8]. 2.2.3 P eak Load P ricin g Peak load pricing is a greatly simplified variant of spot pricing. This approach utilizes a graduated pricing scheme where price is a function of expected dem and. Price varies according to preestablished policies regardless of the current dem and. In an attem p t to reduce dem and, higher prices are charged when usage would tend to rise above the level of capacity. A dditional custom ers are a ttracted during expected off-peak periods by charging lower prices. Boiteux [9] provides an analysis of peak load pricing showing which industries are more likely to obtain equilibrium at an optim al level of output. He concludes th a t an optim al level of production is obtained in industries where to tal dem and can be accurately predicted. Chen and M alinvaud [20, 40] have also studied price im plications and optim ality for lim ited production environm ents. T he peak load pricing policy has been employed in the telephone industry. This pricing policy is well suited for telephony because of its single class of service and its statistically determ ined traffic patterns. A lthough an individual’s dem and ap pears stochastic, the m arket dem and exhibits strong daily and weekly patterns[45]. For sim ilar reasons, peak load pricing has also been employed in th e airline indus try. Section 2.2.6 provides a discussion of how pricing and traffic characteristics in telephone networks compares to th a t in integrated high speed com puter networks. 2 .2 .4 P r io r ity S erv ice P ricin g U ntil th e late 1960’s economists virtually ignored the application of priority m ech anisms to resource allocation. A study conducted by Singer et al. [61] in 1968 presented one of the first research efforts th a t exam ined th e prioritization of com p uter resources. By th e m id 1970’s, 40 out of 45 com puter facilities surveyed had some type of priority pricing algorithm on their tim e-shared m ainfram es [21]. U nder the priority service policy, service providers satisfy requests according to discrete priority levels. This policy has been extensively studied in the literature [6, 12, 17, 22, 42, 48, 70, 71]. Priorities can be established according to a m yriad o f ! 1 disciplines including adm inistrative controls, willingness to pay, application type and j self-selection. Among these policies self-selection has the added benefit of allowing j users to rank their service requests. 16 There are two necessary conditions th a t m ust be present in order for priority pricing to have the desired effect. First, th e prospective service m ust be occasion ally rationed or queued. Second, customers m ust have diverse preferences so th at efficiency gains from differentiation are present. W ithout these conditions it is dif ficult to prioritize and hence to create graduated prices for service requests. T he rate charged for satisfying service requests varies according to the selected or assigned priority. A pricing scheme is introduced to prevent users from always selecting the highest priority. Naor and Yechiali [48, 71] show th a t using queue size as a lim iting quantity cannot lead to an optim al allocation of resources unless prices are sim ultaneously imposed. In [6], Balachandran considers decentralized priority allocation through pricing mechanisms. In [12], Chao and W ilson’s theoretical analysis shows th a t th e increm ental gains for priority service decline rapidly as the num ber of priority classes increases. They show, using a linear dem and function and a uniform supply function, th a t the expected surplus obtained by prioritizing service requests falls sharply as the num ber of priority classes increases. Their study establishes a lower bound on unrealized surplus on the order of ^ where n equals the num ber of priority classes. Therefore, th e benefits of priority service can be realized through the use of a few priority classes. They show th a t m ost of th e potential benefits from priority service can be captured by utilizing three priority classes. In the next section we present our argum ents for selecting priority pricing for use in our work over other pricing models previously discussed. j 2 .2 .5 C om p a riso n o f P rio rity S erv ice to O th er A p p ro a ch es In term s of resource allocation, priority service is clearly superior to flat price with random rationing because the latter approach allocates resources w ithout regard to specific user classes. F lat pricing breaks down because users w ith higher priority requests do not receive b etter service, thereby degrading their social welfare. B ut, does priority service m ake some customers worse off even though it m ay benefit the com m unity at large? In [70], W ilson dem onstrates th a t priority service is Pareto j superior to random rationing w ith a fixed price if prem ia are refunded equally toj i i 17: consumers as dividends. Efficiency gains achieved through priority service can be redistributed to custom ers thereby increasing the net welfare of all subscribers. We have chosen to im plem ent priority pricing in our models because of its sim plicity and effectiveness at m anaging th e allocation of scarce resources. Priority pricing can achieve m ost of the efficiency gains attrib u ted to spot pricing by ra tioning the available supply according to contracts th a t specify each custom ers pri ority. Practical im plem entation of spot pricing presents several difficulties. First, it is expensive to continually inform custom ers about spot prices. Second, it is also expensive for custom ers to continually m onitor prices and to adapt purchases accordingly. Finally, custom ers feel uneasy about unpredictable spot prices which m ake budget forecasts harder to obtain. Practical im plem entations of priority ser vice includes a forward contract where custom ers can obtain services at known rates for a longer period of tim e. The two approaches are differentiated by the length of the reporting interval. Spot pricing is the lim iting case of priority service as the reporting interval approaches zero. As the duration of the forward contract increases, a priority service provider incurs increased risk th a t the actual cost to provide a service differs from the published price. The Chao study [12] shows th at under the assum ption of risk neutrality, spot pricing and priority service are es sentially equivalent from th e perspective of expenditures and expected surplus for each custom er.6 We next evaluate how pricing policies found in telephone networks relate to com puter com m unications networks. i 2 .2 .6 A C om p a riso n o f T elep h o n e an d C o m p u ter C o m m u n ica tio n s N etw o rk s Peak load pricing is effective in the telephone industry because aggregate dem and can be predicted accurately due to the large num ber of users [45]. Since peak pe riods typically occur on weekdays during business hours, prices are raised during [ these periods to reduce dem and to w ithin capacity. This pricing m odel works well 6The study also points out that the providers revenue may slightly differ between t h e ! two approaches (Revenuespot pTicing — Expected(spot price * spot demand) as opposed t o , Revenuepri service = Expected(spot price) * Expected(spot demand)). I I I i I 18. in telephony for the following reasons: 1) by varying prices according to well pub lished policies, dem and can be kept w ithin capacity, 2) custom ers can accurately predict m onthly charges because prices are known in advance and rate changes occur infrequently, and 3) telephone networks were prim arily designed to support low bandw idth voice com m unication; therefore, the single class of service can be efficiently supported by a single tariff assigned to each peak period. There exists several reasons why the peak load pricing m odel breaks down in integrated high speed com puter com m unications networks supporting m ultiple ser vice classes. F irst, unlike telephone networks, integrated high speed networks are designed to m eet a variety of service requirem ents supporting applications such as voice, video, bulk file transfer, electronic m ail, and com puter term inal client and server traffic. A prim ary argum ent in our research is th a t a graduated pricing scheme, not achievable through peak load pricing alone, is required to efficiently utilize th e m ultiple service classes present in these networks. Second, high speed networks support m any bursty traffic sources, creating extrem ely dynam ic traffic conditions. If peak load prices are allowed to vary dynam ically, traffic sources would not be able to accurately predict usage charges thus m aking budget forecasts difficult to obtain. Third, network usage patterns may be difficult to characterize,] thereby m aking peak loads difficult to define. U npredictable usage patterns also] present an argum ent for dynam ically varying peak load prices, which m akes b u d g et! forecasts difficult to obtain. We have explored m any issues related to perform ance and m onetary incentives th a t can be applied to the integration of m ultiple network technologies. Network perform ance incentives offered by current gateway queueing disciplines, packet dis card policies, and admission control policies were described. Resource allocation under pricing policies such as flat pricing, spot pricing, peak load pricing and prior- 1 ity pricing were investigated to balance network perform ance incentives and increase to tal utility in high speed integrated networks. As discussed in C hapter 1, this bal-1 ance is necessary to globally maxim ize user satisfaction w ith service delivered by the network. In th e next chapter, we m otivate our research direction and in subsequent chapters we present our research models and analyses. Chapter 3 Motivation A problem well stated is a problem half solved. — Charles F. Kettering Given the paucity of previously published papers on th e topic of user incentives in m ultiple service class networks, it is natural to ask: why is the question of pricing relevant to com puter networks? We address this question by reviewing th e charac teristics of the current Internet, and then discussing how these characteristics are i likely to change in the design and developm ent of future networks. We also briefly address th e issue of pricing in the context of th e Integrated Services Digital Network (ISDN). Today’s Internet has four characteristics th a t are relevant to our discussion. F irst, the overall bandw idth is quite lim ited (the backbone is currently comprised of T1 and T3 lines). This lim ited bandw idth prevents the widespread usage of certain bandw idth-intensive applications from utilizing th e Internet; for instance, HDTV generates a 120M bit/sec d ata stream under 8:1 encoding. A second characteristic of the Internet is restricted access; for exam ple, N SF’s A cceptable Use Policy (AUP) allows only educational and research institutions to access the Internet. These access restrictions, in addition to controlling the size of the user population, help preserve th e cohesive nature of the user community. T he shared history of creating the i i 201 network, th e large degree of control over technical decisions, th e com m onality of end system hardw are and operating system s, and the preservation of the relatively sm all user com m unity have produced w idespread adherence to socially desirable behavioral norms. Third, the Internet offers a single class of service;1 all packets are serviced on a best-effort, first-in-first-out (FIFO ) basis. This single service class severely lim its th e nature of applications th a t can be adequately supported. Fourth, there are no usage fees; users are not charged on the basis of how m any packets they send. T h at is not to say th a t the networks are free; m ost institutions are charged for access to a regional network. However, these fees are not based on the volume of traffic sent, and in m any cases are not passed back to individual users. Pricing has not been critical in to d ay ’s Internet. However, th e future of in ternetw orking is likely to be quite different w ith respect to each one of the four aforem entioned characteristics; these changes will likely render th e issue of pricing m uch m ore relevant th an it is today. Below, we discuss each one of these topics in tu rn and how they are likely to change in constructing th e networks of tomorrow. F irst, all of the 1.5 M bps T1 backbone links are being upgraded to 45 Mbps T3 lines; further bandw idth increases are expected and gigabit lines, a thousand tim es th e speed of th e current T1 lines, are technically w ithin reach. D ram atic increases in aggregate bandw idth will allow new bandw idth-intensive applications to utilize th e network. Perhaps m ore im portantly, it will also allow future networks to service a m uch larger user community. Second, increases in bandw idth, combined w ith the w idespread availability of personal com puters and th e im m inent availability of residential ISDN, makes it likely th a t future internetw orks will become reachable by th e public. No longer will future networks have, by virtue of artificial access restrictions, a small, technically knowledgeable, and m ostly cooperative user community. As w ith other widely used public facilities, inform al enforcem ent of behavioral norm s is unlikely to be sufficient to ensure socially desirable behavior. T he fundam ental goal of ISDN is to develop an advanced, worldwide, digital telephone system for th e tw enty first century th a t integrates both voice and nonvoice; 1We will use the terms service class, Quality-of-Service (QoS), and Type-of-Service (ToS) in terchangeably. A service discipline that has a QoS mechanism is one in which there are multiple- service classes. I Services (such as electronic m ail, facsimile, video, etc). This undertaking is an international effort underway since th e early 1980’s, and along w ith its successor [Broadband ISDN it is expected to play a crucial role in th e developm ent of future netw orks. Pricing will be critical to th e long term success of this effort in m uch the same way as it has been in existing telephone networks. T h at is, pricing has been used not only to raise revenue, b u t also for encouraging efficient usage of available resources (i.e. to keep dem and w ithin capacity). T hird, th e future traffic control m echanisms, by which we m ean th e switch queue ing algorithm s as well as the host congestion control algorithm s, are likely to be m uch m ore sophisticated than th e single service class in the current Internet. There is active debate as to exactly w hat form these controls will take (reservation vs. best-effort, connections vs. datagram s, dum b hosts and sm art switches vs. sm art hosts and dum b switches, etc.). See Clark et al. [16] for a brief overview of th e literatu re and one specific proposal. However, the proposed m echanism s all have the same goal of supporting a wide variety of service classes. This agreem ent on the goal, despite the disagreem ent on the m eans, is due to widespread consensus on two points. One point of consensus is th a t applications have very different service require m ents. For instance some applications, like electronic m ail, can tolerate significant delay w ithout users experiencing discernible perform ance degradation, while other applications, such as packetized voice, degrade perceptibly w ith even extrem ely small delays. Similarly, some applications are relatively insensitive to packet loss while others are not, and some applications can adjust to reduced bandw idth while others cannot. T he range of applications, and the diversity of service requirem ents, is likely to grow rapidly in the near future. Thus, it is crucial for the evolution of com puter networks, e.g. the future Internet and ISDN, th a t m eans be found for m eeting these increasingly varied service requirem ents. T he other point of consensus is th a t networks can m ore efficiently m eet these • varied service requirem ents if the network offers m ultiple classes of service, so th a t users can choose the class of service th a t is m ost appropriate for their application.2 2Note that this second point of consensus is not entirely trivial; one might contend that building a single class network with sufficient speed to m eet the m ost stringent performance requirements is easier than building a slower network with m ultiple service classes. Also, we have used the term | 22 ' Application Parameters Application Characteristics Type of Usage single-user, multi-user, interactive, batch Unit of Service access, session, connection, flow specification, packet, byte Service Quality reliable, unreliable, delay sensitive, delay insensitive, variability of delay, route, bandwidth, throughput Service Usage advanced reservation, walk-in reservation, preemptable reservation, best effort Table 3.1: Param eters of Service The network can then, in periods of resource contention, focus its resources on the perform ance sensitive applications and avoid squandering them on applications th at are not perform ance sensitive. Typically, not all service classes get b etter perfor m ance under this m ultiple service class scheme. For exam ple, traffic in a lower quality service class at tim es will receive worse perform ance th an it would in the current single class of service scheme. The purpose of m ultiple service classes is to degrade perform ance for those applications th a t are least sensitive in order to im prove perform ance for those th a t are m ost sensitive.3 Table 3.1 contains a gen eral param eterization for network applications. The first colum n identifies various netw ork application param eters. The second column lists several characteristics for each service param eter. In C hapter 4, we describe exam ples of applications in term s of these characteristics (see Table 4.1). Lastly, in contrast to th e current Internet, we believe it is likely future networks will im plem ent usage fees regardless of how th e cost of th e network is financed.4 appropriate in two ways. Appropriate service classes are not those that m axim ize the individual user’s performance, but those that m axim ize overall system efficiency; this will be discussed more fully in Section 4.2. Appropriate pricing policies are, in the terminology of Section 4.2, adoptable and acceptable pricing policies. 3We hasten to add that network performance is measured along m any different dimensions (delay, packet loss, delay jitter, bandwidth, etc.). Thus, it is a convenient, but occasionally i misleading, simplification to talk about better or worse service. 4Again, these fees m ight not be monetary in nature, but rather quotas or some other adminis- | trative form. We will, for the sake of brevity, include all such mechanisms under the umbrella of monetary incentives in this paper. Furthermore, we should note that there is significant disagree- | m ent about how to best finance computer networks. Some argue for continued heavy subsidies | from government, others argue for self-financing through usage fees. We are not entering this debate. We are merely assuming that, in order to make m ulticlass service disciplines viable, some j This prediction is perhaps th e m ost controversial of those m ade here, but we feel th a t th e presence of m ultiple service classes makes this inevitable. M ultiple service classes introduce the issue of perform ance incentives. Users n aturally w ant good perform ance from their network. Once they are equipped w ith an action th a t influ ences the perform ance they receive, there is im m ediately an incentive to request the service class th a t maximizes their perform ance. In the absence of any other consid eration, there is nothing to m otivate users to indicate th a t their applications are less perform ance sensitive. However, by pricing the service classes appropriately, one can offer m onetary incentives for reducing th e quality of service requested. We expect pricing of th e various service classes to be a vehicle commonly used to encourage users to m ake reasonable choices. Thus, we believe th a t pricing will play an integral role in the design and develop m ent of future networks, and th a t the im plem entation of appropriate pricing policies will be a crucial enabling technology. One key question is: can we set prices in such a way th a t th e perform ance penalty received for requesting a less-than-optim al ser vice class is offset by the reduced price of the service, while at the same tim e not m aking optim al service classes so expensive th a t even perform ance-sensitive users do not use them ? If we cannot answer this question in the affirm ative, then much of the technical work on m ulticlass service disciplines will be rendered ineffective because users will not employ the service classes in an appropriate way. Further, if it can be shown th a t under certain conditions charging increases ones u tility then charging per se is not som ething th a t should be shunned. service-class dependent usage fees are necessary as incentives to make users choose the appropriate ' service classes. ■ Chapter 4 Pricing as a Form of Incentive A teacher who can arouse a feeling for one single good action accom plishes more than [s/]he who fills our memories with rows and rows of natural objects, classified by name and form. — Johann Wolfgang Von Goethe Network perform ance, at least from the perspective of end users (applications), is not com pletely determ ined by th e technical characteristics of th e network. Network perform ance is also a function of the offered load. This statem ent is analogous to the fact th a t one’s driving tim e is not ju st a function of the top speed of the vehicle or th e speed lim it of the road, but also depends on the level of traffic on the road. The aggregate traffic load on a network is the result of m any users’ individual decisions about w hether and how to use the network, and these decisions are affected by the incentives these users encounter when using th e network. Therefore, in addition | to the technical specifications of the network, the issue of user incentives m ust be considered when discussing network perform ance from the perspective of end users. Note th a t these user incentives can take m any forms: perform ance incentives, m onetary incentives, adm inistrative incentives, or social incentives, to nam e a few. 25 This chapter addresses th e introduction of user incentives in m ultiple service class networks. We focus on one particular aspect of user incentives; th e intertw in ing of pricing policies, which produce m onetary1 incentives, and m ulticlass service disciplines, which produce perform ance incentives. O ur goal is to articulate pre cisely some fundam ental issues involved in th e interplay betw een pricing policies and m ulticlass service disciplines and lay th e groundwork for future research. We present an abstract form ulation of our problem in Section 4.2. This form u lation allows us to articulate precisely the roles of service disciplines and pricing policies and then discuss how they interact. In Section 4.3, we present an exam ple of th e interplay between pricing and service disciplines. We consider a network w ith a simple tw o-priority service discipline and several different application types (electronic m ail, packetized voice, file transfer, and interactive term inal connection) running over standard transport-layer protocols. Using packet-level sim ulations of this network we then compare two different pricing policies: 1) flat pricing, where a uniform per-byte price is charged and is therefore service-class insensitive, and 2) priority pricing, where a higher per-byte price is charged for the high priority traffic and is therefore service-class sensitive. Keeping th e overall level of revenue generated fixed and m easuring user satisfaction as a function of both the cost and quality of service received, we find th a t in each of th e several netw ork configurations sim ulated one can always find priority prices such th a t the users of every application ty p e2 are 1) m ore satisfied w ith the service-class sensitive priority pricing scheme th a n they were w ith the service-class insensitive flat pricing scheme, and 2) when m axim izing their own satisfaction choose priority settings th a t m axim ize th e overall network efficiency. The former p art of this statem ent is not necessarily obvious, since users whose prices are raised will often pose an initial objection. Thus, ap propriate pricing policies allow us to spread the benefits of m ultiple service classes! around to the users of all application types, rath er th an ju st having these benefits rem ain exclusively w ith the users of applications which are perform ance sensitive. 1 Pricing can refer to forms of incentives other than money; for instance, one can price service in; terms of administrative incentives such as quotas or logs. W hile our framework could be generalized j to these other forms of pricing, for the sake of simplicity we will refer only to monetary incentives; in this dissertation. ' 2A s will be explained in Section 4.3, in our exam ple we consider the set of users who are using! a particular application type as a single entity for the purposes of the analysis. j The problem we address is sim ilar to and th e conclusions we reach are consistent w ith those of the priority pricing literature in economics, which discusses th e supply of nonstorable goods like electrical power [70]. 4.1 Problem Statement and System Models M ultiple service classes introduce the issue of perform ance incentives. Users n atu rally want good perform ance from their network. Once they are equipped w ith an action th a t influences the perform ance they receive, there is im m ediately an incen tive to request th e service class th a t m axim izes their perform ance. In the absence of any other consideration, there is nothing to m otivate some users to indicate th at their applications are less perform ance sensitive (which would thereby degrade the perform ance they receives under some network conditions) th an others. Perhaps in a small and cooperative user com m unity the behavioral norm of requesting the appropriate service class can be enforced informally. .B ut, in a public network with a large and relatively anonymous user com munity, we do not expect th a t such in form al enforcem ent mechanisms will be sufficient. However, by pricing the service classes appropriately, we can offer m onetary incentives for reducing the quality of service requested. We expect pricing of the various service classes to be a vehicle commonly used to encourage users to m ake reasonable choices. T here are two distinctions th a t separate this work from the traditional literature found in economics and telephony. F irst, our practice of pricing the service classes, i.e. priority levels, as opposed to pricing th e actual goods or application services them selves, is not the classic externalities problem found in microeconomics. Appli cation utilities depend on reliability and there is a complex nonlinear relationship betw een service classes and end user application service. If we were to price the goods, then we would have to guarantee the level of service for a given class, i.e. ■ drop rate, delay, throughput, etc. G uaranteed reservations lim it the effectiveness; of statistical m ultiplexing and can at tim es lead to underutilization of th e network 1 [16]. Further, our study shows th a t the vast m ajority of service requests fall w ithin acceptable levels so th a t guaranteed reservations are not needed. Second, studies conducted in telephony do not relate to our analysis because telephone netw orks! do not offer m ultiple service classes at the call level. Therefore, they do not assess quality verses cost tradeoffs for individual users, which is th e im petus for our work. We believe th a t pricing will play an integral role in the developm ent of future n et works, and th a t th e design of appropriate pricing policies will be a crucial enabling technology. Throughout th e rem ainder of this chapter we form ulate our m odel and dem onstrate its effectiveness w ith several exam ple networks. 4.2 Abstract Formulation In this section, we present an abstract form ulation of a service discipline and a pricing policy. W ith this form ulation we are able to state an optim ality criterion for service disciplines and then, for a given service discipline, an acceptability criterion for a pricing policy. Throughout this section, we consider a fixed network w ith a fixed set of n potential network users (who m ay or m ay not decide to use the netw ork). The form ulation borrows heavily from the field of economics, particularly in the use of utility functions, Nash equilibria, and Nash im plem entation [33, 43, 50]. Let Si denote a characterization of th e network service received by th e i ’th user (which m ay be no service at all). Let K'(sj) denote th e i ’th user’s level of satisfaction w ith a given network service s,-. T he functional dependence of Vi on s; reflects the particular nature of th e application being run by user i. The unit of V is money; Vi reflects, up to an arb itrary additive constant, how m uch m oney user i would be willing to pay for a particular level of service. Thus, if a user is charged an am ount C i for th a t service, her overall level of satisfaction (up to the same arbitrary additive constant), which we denote by Ui, becomes: Ui = Vj(s*) — c8.3 In our m odel of the service discipline, each user sends to the network a signal, or request, < 7 i which lies in some space S of possible service requests. This term request should not be interpreted as necessarily involving an explicit call set-up; in this abstract form ulation the signal could be anything, including the unreserved! transm ission of packets. The resulting network service s; received by each user is aj function of th e vector of requests: Si(a). The signal space < 5 and th e function s;(a); I com pletely specify th e netw ork’s service discipline. i ( 3This m odeling choice contains the technical assumption that the preferences are separable. > Let us denote by cropt the vector of signals4 th a t m axim izes the sum of the V's: n n J 2 V i(a opt) > ^ V i { a ) fo r all a & S n i= l i= l Let V opt denote th e optim al sum: V opt = Vi{aopt). T he netw ork’s resources are used m ost efficiently, i.e. produce the highest to tal satisfaction, when th e users send th e request vector 5 opt. Notice th a t here efficiency does not refer to any network- oriented m easure (such as link utilization) but rather refers only to th e level of user satisfaction th a t the network delivers. For a given network configuration, one service discipline is deem ed superior to (i.e., m ore efficient than) another if it produces a larger value for V opt. For a given netw ork configuration, an optim al service discipline is one which is not inferior to any other service discipline. We expect th a t m ulticlass service disciplines will have higher values for V opt th an single-class service disciplines in m ost netw ork configurations; this expectation is merely a precise form ulation of the observation in C hapter 3 th a t m ulticlass service disciplines could m eet users’ needs m ore efficiently th an single-class service disciplines. In th e preceding paragraph we defined a service discipline as a function th at takes a vector of requests a as input and then assigns netw ork service s2(a) to each user. Similarly, a pricing policy (or pricing scheme) is a function th a t takes a vector of requests a as input and then assigns costs c,(<?) to each user. Given a pricing scheme and a service discipline we can consider Ui to be a function of < ? : Ui(a) = Vi(si(a)) - c fa ). O ur assum ption is th a t each user acts selfishly, and will request the service th a t m axim izes her individual level of satisfaction. This assum ption implies th a t th e resulting request vector a will have the property th a t no user, by unilaterally changing her own request cq, can increase her utility. In economics this notion is referred to as a Nash equilibrium (see [33, 50] for basic definitions, and [43] for a, m ore comprehensive treatm en t). More formally, a is a Nash equilibrium if for all i\ and all cr € S we have U fa ) > U fa ^ a ). Here we use the notation th a t denotesj 4There m ay be several such optim al vectors. For convenience, in what follows we assume that I there is only one. | th e vector w ith the i ’th com ponent given by a and all other com ponents j given by crjy i.e. the input vectors a and a\cr differ only in th e i ’th com ponent. O ur goal is to have the network operate at peak efficiency, which happens only when th e vector of requests is a opt. Given our assum ption th a t the selfish behavior of individual users will result in a being a Nash equilibrium , our goal of network efficiency requires th a t a°pt be a Nash equilibrium . U nfortunately, in th e absence of a pricing scheme this is rarely th e case. Recall th a t the criterion defining a opt refers only to the sum; any individual user m ight receive a very low value for Vi(aopt). Furtherm ore, w ithout a pricing scheme (i.e., Ci(a) = 0 for all i and all <x), th e Nash equilibrium condition requires th a t Vi(cr) — K(<?|*cr) > 0. Thus, in Nash equilibrium , no user can im prove her perform ance Vi by changing her request. This condition is unlikely to be m et unless every user is requesting highest quality service; however, the optim al request vector a opt is unlikely to be one in which every user is requesting highest quality service. Thus, w ithout a pricing policy it is im probable th a t the network resources will be used efficiently. W hen we consider a nontrivial pricing policy, the Nash equilibrium a obeys the following relation: V ( a ) — V ( a |*<t) > Ci{a) — Cj ( <Thus, at a Nash equilibrium , any im provem ent in service quality obtained by subm itting a different request is offset by the resulting increased cost; similarly, any decrease in cost obtained by subm itting a different request is offset by the resulting decrease in service quality. For a given network configuration, we say th a t a pricing scheme is acceptable if th e only Nash equilibrium is a opi. An acceptable pricing scheme is one in which the selfish behavior of users results in an efficient usage of th e netw ork’s resources. In economics, this acceptability condition is called Nash im plem entation of th e Pareto correspondence [43]. If there is a current status quo pricing scheme, we say th a t a new pricing scheme j is adoptable if all users are at least as satisfied (and at least one user strictly more] satisfied) w ith th e new scheme. This addresses the political process of adopting a new pricing policy. If no one would lose by th e adoption of a new pricing policy, it is less likely to run into political opposition. This abstract form ulation allows us to define precisely the role of service disci- I ' plines and pricing policies. T he role of an optim al service discipline is to maximize: V opt, regardless of the resulting user incentives. The role of an acceptable pricing policy is to ensure th a t user selfishness will lead to the users choosing a opt and thus will m axim ize th e efficiency of the network. Furtherm ore, the role of an acceptable and adoptable pricing policy is to m ake every user at least as satisfied w ith the new pricing policy, so th a t th e benefits of the increased efficiency are spread around to all users. ft m ay be possible to further increase to tal utility and hence netw ork efficiency by allowing coalitions to form among various user classes; however, we do not allow cooperation among user classes. Cooperation between application classes requires an unlikely degree of coordination. 4.3 Example We now have an abstract form ulation of the interaction between pricing policies and service disciplines in com puter networks. However, th e m ost pressing challenge currently facing network designers is to develop the optim al service disciplines (th at is, the ones which have the m axim al F opt,s). W hile m uch basic research has been done in this area, no consensus has yet been reached, by either the m arketplace or th e research community, on th e nature of these new service disciplines. Only when these new service disciplines are identified will it be possible to develop the associated acceptable and adoptable pricing policies. In th e m eantim e, we present a qualitative fram ework for future pricing design. O ur goal in this section is to illustrate some of th e basic ideas of such pricing policies through the sim ulation of a sim ple example. The exam ple utilizes an extrem ely simple m ulticlass service discipline, one th at involves only two service classes, so th a t th e pricing issues are not obscured by t h e ! j technical details of th e service discipline; obviously, we expect th a t future networks j will have substantially m ore com plicated m ulticlass service disciplines. However, the f network context is realistic, in th a t we consider a standard T C P /IP ([56]) netw ork' and our sim ulations are done at the packet level. We focus on several sim ple network j configurations (where a network configuration defines both th e network p ro p erties! and the user population). Each network user is represented by an instance of o n e , of four different application types: electronic m ail, real-tim e packetized voice, a file transfer service, or a rem ote login service. Associated w ith each application type is a function VappiiC aiion^s) which describes how the perceived perform ance of the ap plication depends on th e network service. Also, we associate w ith each application a particular m odel of traffic generation (specified by several user-specific param eters). We outline the details of our exam ple in the following subsections. We first describe the service discipline and pricing policies, and then discuss how the abstract form ulation should be applied to this example. We next define the V a p v u cat i o n s for th e various applications, and then, after reviewing some m iscellaneous details of the sim ulation, describe the various network configurations considered. We conclude our treatm en t of this exam ple w ith a presentation and discussion of the sim ulation results. 4.3.1 S erv ice D isc ip lin e an d P r ic in g P o lic ie s At an abstract level, there are only two decisions faced by a switch. W hen the transm ission line is free and there are packets in the queue, th e switch m ust select the next packet to tra n sm it.5 W hen a packet arrives and there is no room in the queue, th e switch m ust decide which packet to discard. T he traditional FIFO service discipline, which provides only a single service class, is to queue th e packets in order of increasing tim e-of-arrival and then transm it the packet at the head of the queue and, when necessary, discard the packet at th e tail of th e queue. In our example, we use th e sim plest m ulticlass service discipline, which is merely to extend the FIFO service to have two service classes: high priority and low priority. T he switch then (logically) keeps a queue w ith th e high priority packets arranged in increasing tim e-of-arrival, followed by th e low priority packets arranged in increasing time- of-arrival. T he switch transm its th e packet at the head of the queue and, when necessary, discards the packet at th e tail of the queue. We consider two different pricing schemes. T he first is a flat per-byte price applied to all packets traversing a ! link, call it Pfiat- In the second pricing scheme, called priority pricing (based on a | theoretical analysis of a sim ilar problem in [70]), we charge different per-byte prices j 5We generalize the packet transmission function to include route selection. The packet trans m ission function is not specific to any particular routing algorithm. | 3 2 ; ------------------------------------------------ _ .. . _ . _ . .i for th e two priority classes. Let us denote these two per-byte prices by phigh and Plow; clearly we should set phigh > Plow so th a t the m onetary incentives encourage th e use of th e low priority service class. In order to facilitate direct com parison between th e two pricing schemes in the sim ulation study presented below, we require th a t, in equilibrium , b o th pricing schemes recover th e same net revenue R = this case, revenue neu tra lity m eans choosing Pfiat and phigh and piow so th a t the to tal revenue is equal to R , and thus the absolute values of the prices in the two schemes will depend on the offered load. 4 .3 .2 D e fin itio n o f V a p p l i c a t i o n s To study user satisfaction in a network w ith num erous traffic sources and distinct types of service, we have chosen a set of applications w ith diverse service require m ents. T he following applications will be considered in this study: electronic mail (Em ail), a file transfer service (F T P ), a rem ote login service (Telnet), and real-tim e packetized voice (Voice). We discuss each one of them in tu rn , giving a general de scription and th en presenting our perform ance evaluation criteria, V aPPi i c a t i o m th at roughly models th e application’s service requirem ents. These functions oversimplify th e tru e relationship betw een application perform ance and netw ork service, b u t our . purpose is to capture the essence of th e relationship. We defer the description of the detailed traffic generation characteristics of these applications to Section 4.3.4. However, it is relevant to our current discussion to note th a t each of th e appli cations is invoked m any tim es during the period of evaluation. Accordingly, the user’s perception of the application perform ance reflects the average perform ance throughout this interval; thus, each V a p p iicat i o n is a function of average quantities, such as average delay. These average quantities are the service descriptors st - used in th e abstract form ulation. Also, recall th a t V a p p U c a tio n is defined up to an arbitrary additive constant. We have chosen, for three of our applications (Em ail, T e ln e t,, and Voice), to have Vappucati0 n < 0 and let \ \ V a p p u c a ti o n \\ reflect the level of perceived J perform ance degradation of the application. For the fourth application (F T P ), we have V a p p lic a tio n > 0 and let ||V a p p u Ca tio n \\ reflect th e level of satisfaction. We should j 33 Application Type Application Characteristics Telnet delay sensitive, reliable, interactive Voice delay sensitive, jitter sensitive, no retransmission, unreliable, multi-user FTP throughput sensitive, reliable, pseudo-interactive E-Mail delay insensitive, reliable, asynchronous multi-user Table 4.1: A pplication C haracteristics also note th a t the constants appearing in th e definitions for V a p p u cat i o n are chosen so th a t the dynam ic ranges of the functions have sim ilar m agnitudes. Table 4.1 sum m arizes the perform ance characteristics for each of the four appli cations under consideration (see Table 3.1 for a general param eterization of charac teristics for netw ork applications). A detailed explanation of each application along w ith the specific VappuC ation definition is provided in th e paragraphs th a t follow. Em ail is used for m ulti-user, asynchronous com m unication. Since instantaneous delivery is not expected, we assume users care m ostly about their m ail arriving w ithin some delay on the scale of m inutes. For messages delivered w ithin this bound, we assum e th e user has only a slight preference for reduced delays. We m odel these service requirem ents through: VEmaii = — 0.1 (average message delay, in seconds) — (% of messages not delivered in loose delay bound of five m inutes) In our m odel, F T P is a single user pseudo-interactive application. Since F T P users often await com pletion of the application before proceeding w ith other tasks, we assum e they w ant the network to deliver relatively prom pt service. This expec tation m ust be tem pered by the physical lim its of th e underlying network. T he ideal transfer tim e of a file is the tim e it would take the file to be transferred if there was no other traffic on th e netw ork (and the flow control algorithm in th e underlying; tran sp o rt layer allowed for full utilization of th e available bandw idth). Defining! the norm alized throughput of a particular file transfer to be the ratio of the ideal! transfer tim e to th e actual transfer tim e, we m odel the F T P service requirem ents by: V f t p — 100(average norm alized throughput) Telnet exemplifies a tru ly interactive application. A user conducts a Telnet session as a prim ary task and expects real tim e responses. We assum e Telnet users are sensitive to packet delays th a t exceed a few hundredths of a second. Since rem ote echoing is used in m ost Telnet connections the relevant delay is the roundtrip tim e from th e transm ission of a packet to its acknowledgment. These requirem ents are expressed by: Vreinet = — (average packet round trip tim e, in m illiseconds)/10 Voice is a real tim e application which is extrem ely sensitive to delay; voice applications cannot tolerate absolute delays much above 100 milliseconds [24].6 The im provem ent in perform ance when the delays are reduced well below this lim it is slight. At th e same tim e, voice differs from th e other applications considered in th at the requirem ent for 100% reliability is removed. H um an speech includes enough redundancy to allow correct in terpretation in the presence of some d ata loss. This allows th e voice application to trad e reliability for reduced delivery delay when it cannot get both. We consider a m odel of a voice application in which packets thatj do not m ake a tight delay bound (set at 100ms) are discarded; from th e perspective of th e application dropped packets are no different from delayed ones. L etting d denote th e average one-way delay of th e voice packets (m easured in m s), our assumed application perform ance function is: Vvoice = — (% of packets not obeying tight delay bound) — d / 100 | 6Voice is also sensitive to the variance in delays, often referred to as jitter, but we do not m odel that dependence here. I I 35 _ _ ! 4 .3 .3 A p p ly in g th e A b str a c t F o rm u lation We have not attem p ted to capture overall dem and elasticity in this m odel, i.e. where users could choose to adjust their traffic generation p attern (or even cease to use the network) if the prices were too high. This enhancem ent to th e m odel will be discussed in C hapter 6 where we im plem ent an im plicit elastic dem and function in the context of our guaranteed Quality of Service (QoS) models. In this chapter we m ake th e simplifying assum ption th a t the to tal traffic generated by a user is independent of th e price and study the effect of our two distinct pricing policies. Hence, we m odel only th e users’ service class decisions. Therefore, in this exam ple, th e requests er; are m erely the priority settings on th e packets. The only action we allow users is to select their priority settings on their packets. T he packet generation p a ttern is a function of the application type (defined in m ore detail in Section 4.3.4) and is independent of this priority selection. In the abstract form ulation, each user could individually choose their request Gi. However, in our exam ple we have chosen to have each instance of a particular application (Em ail, Voice, Telnet, and F T P ) use the same priority settings. We m ake this choice for two reasons. First, we assume th a t it will be the application th a t invokes th e underlying network transport protocols and thus determ ines the priority settings; th e typical user, we assume, will not be intervening m anually in this process. Second, two users of the same application will want to set their priority levels differently only if they know th a t th e network conditions along their respective transm ission paths are different. We assum e th a t the underlying netw ork will be relatively invisible to th e typical user, so th a t this inform ation will not be available.7 The im plication of this m odeling choice is th a t to apply the ab stract form ulation to this m odel, we should assum e th a t it is the application type th a t is choosing the request Gi and th a t th e V of th e application type is th e sum of the Vi’s of the users of th a t application. T he Nash equilibrium conditions, as well as th e acceptability and adoptability conditions, m ust be modified in the same way. In m odifying th e Nash equilibrium conditions in this m anner, we are no longer adhering to the classical Nash definition found in economics. Technically speaking, 1 N ash equilibrium is a strategic equilibrium where the users’ selfish behavior is aj 7This assumption, while widely held, is a debatable normative statem ent about future networks. \ I 36 gam e betw een individual users. In our m odel, the selfish behavior becomes a game betw een application designers, and priorities are established at th e application level. U nder th e flat pricing scheme, it is clear th a t each application type will choose to request high priority service. This choice occurs because there is no m onetary incentive to request low priority service and, if there is any congestion in the network, there is a perform ance incentive to request high priority service. We denote by V ^lat th e value of Y a =\ V when all applications request high priority service. U nder the priority pricing scheme, the situation is less obvious. There is a perform ance incentive to request high priority service and a m onetary incentive to request low priority service. T he service request th a t m axim izes a user’s utility will depend on the values of pkigh and Plow, as well as on the traffic load in the network. Thus, th e Nash equilibrium priority requests will depend in detail on th e network configuration. Our objective is now to find, for each network configuration, prices phigh and piow such th a t priority pricing is acceptable, i.e. th a t the selfish Nash equilibrium results in priority settings for each application type th a t m axim izes the overall level of satisfaction. Furtherm ore, we want to find adoptable priority prices, in th a t every application type is at least as well off w ith priority prices as they were under the flat pricing scheme. 4 .3 .4 S im u la tio n D e ta ils The applications are built upon two transport protocols. Em ail, F T P , and Telnet use T C P [56] whereas Voice uses UDP [55]. UDP was chosen for Voice because, given th e strict delay constraints of th a t application, retransm issions of dropped packets are not useful. As m entioned in Section 4.3.2, users repeatedly request service from their appli-j cation, and the application’s perform ance is averaged over all such instances. Each request can be characterized by a size, s , and the tim e interval, t, from th e last invo cation of th e application. We have m odeled this user behavior by a random process, w ith both the request size and th e tim e interval being exponentially distributed random variables w ith m eans s and t respectively. \ For Em ail and F T P , the size of a request refers to th e size of the message or file to be transm itted. These messages and files are tran sm itted using a m axim um packet size of 500 bytes. For Telnet, th e size of a request is the num ber of characters generated in a burst; each character is tran sm itted and echoed separately, using 50 byte packets.8 A voice request is a conversation; th e size of the request is th e duration of th e conversation. Each conversation is m ade up of several talk spurts; during a talk spurt, 180 byte packets are tran sm itted in packet trains supporting a 64 Kbps peak d a ta rate. T he to tal sim ulation tim e was 90 m inutes per run, not including an initial warm up period of two m inutes. As stated before, when com paring various pricing schemes, we hold fixed the to tal revenue. For this exam ple, we set the to tal revenue R to be 100. 4 .3 .5 N etw o rk C o n figu ration s We study the interaction between th e service discipline and the pricing scheme on seven sim ple network configurations. A configuration is specified by th e network topology and th e user population. T he seven configurations we study are based on three different netw ork topologies, which are labelled A, B, and C and are depicted in Figures 4.1-4.3. The figures depict th e transm ission lines, as well as th e location of the various switches and network hosts. T he links th a t connect two switches (as opposed to connecting a host to a switch) are called backbone links and are depicted in the figures w ith thick lines. The user population of the seven configurations investigated in our sim ulation study are described in Tables 4.2-4.8. T he final colum n of these tables lists the source host and destination host (labelled by the host num ber depicted on the associated netw ork topology diagram ) of each instance of a given application type and given traffic generation param eter description (s,t). Furtherm ore, Table 4.9 describes th e relative com position of th e traffic load in th e seven configurations, listing the percentages of th e num ber of packets generated and th e num ber of bytes generated by each application type. 8We m odel only the traffic generated by the Telnet client. I I i I 38 ■ Switch 2 Switch 1 Figure 4.1: Network Topology A (Host l)--------------^Switch^ 1 (s witch^ ^Switch^ -------------- (H ost 3) (Host 2) Figure 4.2: Network Topology B Switch 7 Switch 5 Switch 6, (H ost l ) - Switch 3] Switch 4 Switch 2 Switch 1 ] Figure 4.3: Network Topology C application type s t (src host, dst host) Telnet 9 pkts 4 sec (1.2) 6 pkts 2 sec (1.2) Voice 70 sec 90 sec (1,2), (1.2), (1.2), (1,2) FTP 100 KB 16 sec (1,2) 500 KB 31 sec (1,2) 1 MB 87 sec (1,2) 1 MB 98 sec (1,2) E-Mail 5 KB 6 sec (1,2) 10 KB 8 sec (1,2) 15 KB 8 sec (1,2) 50 KB 13 sec (1.2) 100 KB 19 sec (1,2) Table 4.2: Configuration 1 on Network Topology A. application type s t (src host, dst host) Telnet 9 pkts 4 sec (1.2) 6 pkts 2 sec (1,2), (1.2) Voice 70 sec 90 sec (1,2), (1,2), (1,2), (1,2) FTP 100 KB 16 sec (1,2) 500 KB 50 sec (1,2) 1 MB 98 sec (1,2) E-Mail 5 KB 6 sec (1,2) 10 KB 8 sec (1,2) 15 KB 8 sec (1,2), (1,2) 50 KB 13 sec (1,2), (1,2), (1,2) 100 KB 19 sec (1,2), (1,2), (1,2) Table 4.3: Configuration 2 on Network Topology A. application type s t (src host, dst host) Telnet 9 pkts 4 sec (1.2) 6 pkts 2 sec (1.2), (1,2) Voice 70 sec 90 sec (1,2), (1,2), (1,2), (1,2), (1,2), (1,2), (1,2), (1,2), (1,2) FTP 100 KB 16 sec (1,2) 500 KB 50 sec (1,2) 1 MB 98 sec (1,2) E-Mail 5 KB 6 sec (1,2) 10 KB 8 sec (1,2) 15 KB 8 sec (1,2) 50 KB 13 sec (1,2), (1,2) 100 KB 19 sec (1,2), (1,2) Table 4.4: Configuration 3 on Network Topology A. application type s t (src host, dst host) Telnet 9 pkts 4 sec (1,2) 6 pkts 2 sec (1,2), (2,1) Voice 70 sec 90 sec (1,2), (1,2), (2,1), (2,1) FTP 100 KB 16 sec (1,2) 500 KB 31 sec (2,1) 1 MB 87 sec (1,2) 1 MB 98 sec (2,1) E-Mail 5 KB 6 sec (2,1) 10 KB 8 sec (1,2) 15 KB 8 sec (1,2) 50 KB 13 sec (1,2) 100 KB 19 sec (2,1) Table 4.5: Configuration 4 on Network Topology A. application type s t (src host, dst host) Telnet 9 pkts 6 pkts 4 sec 2 sec (1,3) (1,2), (2,3) Voice 70 sec 90 sec (1,3), (1,3), (1,2), (1,2), (2,3), (2,3) FTP 100 KB 500 KB 1 MB 1 MB 16 sec 31 sec 87 sec 98 sec (1.3), (2,3) (1.3) (1,2) (2.3) E-Mail 5 KB 10 KB 15 KB 50 KB 100 KB 6 sec 8 sec 8 sec 13 sec 19 sec (1,2) (1.3) (1.3), (2,3) (1.3), (2,3) (1,2) Table 4.6: Configuration 5 on Network Topology B. application type s t (src host, dst host) Telnet 9 pkts 6 pkts 4 sec 2 sec (1,6), (4,2), (5,6) (1,2), (4,3), (5,3) Voice 70 sec 90 sec (1,2), (1,2), (1,6), (1,6), (4.2), (4,2), (4,3), (4,3), (5.3), (5,3), (5,6), (5,6) FT P 1 MB 1 MB 87 sec 98 sec (1,2), (4,3), (5,6) (1,6), (4,2), (5,3) E-Mail 50 ICB 100 KB 13 sec 19 sec (1.2), (1,6), (4,2), (4,3), (5.3), (5,6) (1.2), (1,6), (4,2), (4,3), (5.3), (5,6) Table 4.7: Configuration 6 on Network Topology C. application type s t (src host, dst host) Telnet 9 pkts 4 sec (1,6 , (2,4 , (6,5) (6,3), (7,3) 6 pkts 2 sec (2,1 , (4,3 , (5,3) (6,3) Voice 70 sec 90 sec (1,2 , (2,1 , (1,6) (6,1), (2,4), (4,2 , (4,3 , (3,4) (5,3), (3,5), (5,6 , (6,5 , (4,3) (3,4), (5,3), (3,5 , (5,6 , (6,5) FT P 1 MB 87 sec (1,2 , (3,4 , (5,6) (6,3) 1 MB 98 sec (6,1 , (2,4 , (5,3) (7,6), (7,3) E-Mail 50 KB 13 sec (1,2 , (1,6 , (4,2) (4,3), (5,3), (6,5 , (7,6 , (6,3) (3,7) 100 KB 19 sec (2,1 , (6,1 , (2,4) (3,4), (3,5), (5,6 , (6,7 , (3,6) (7,3) Table 4.8: Configuration 7 on Network Topology C. All links which connect two switches in a given netw ork topology have the same speed, which we refer to as th e backbone speed, and have a constant latency of 10msec. All links connecting hosts to-switches are always 10Mbps regardless of the backbone speed, and have a latency of 1msec. For each netw ork configuration, we perform ed sim ulations w ith six different backbone speeds. The seven configurations were chosen to represent a wide range of topologies and traffic p atterns. T he first configuration was designed to provide some baseline d ata on a very sim ple network topology and traffic p attern. Configuration 1 uses network topology A, which has only a single backbone link, and has only one-way traffic (i.e., all d ata packets traveled in the same direction on th e backbone link). Configurations 2 and 3 also use th e same simple network topology A and have only one-way traffic, but have different application m ixtures th an Configuration 1; Configuration 2 has m ore Em ail traffic and Configuration 3 has m ore Voice traffic. Configuration 4 uses th e same netw ork topology A, but has two-way traffic (i.e., there were d ata packets traveling in both directions on the backbone link9). Configuration 5 uses| the slightly m ore com plicated network topology B which has two backbone links;, i th e traffic load has only one-way traffic. Configurations 6 and 7 use th e m uch m ore | com plicated netw ork topology C, which has seven backbone links. Configuration! 9 Zhang et al. [75] observe that the network dynamics with two-way traffic can be very different: than the dynamics with only one-way traffic. j I 4 3 ' 6 has only one-way traffic, and Configuration 7 has two-way traffic. Thus, these seven configurations allow us to explore th e effects of different application m ixtures, one-way versus two-way traffic, and varied network topologies. 4 .3 .6 R e su lts Tables 4.10-4.16 contain the sim ulation results for the various configurations. For each configuration, we exam ine six different backbone speeds (recall th a t in the m ulti-link networks, all links connecting two switches had th e same speed). For each configuration and backbone speed, th e Tables 4.10-4.16 contain th e following inform ation: average link utilization, th e optim al priority settings a opt (displayed as a string of digits a x e i n e t , c v o i c e , & f t p , where 2 indicates high priority and 1 indicates low priority), V opt, V ^lat, and three price ranges. N ote th a t given a priority setting and phigh, th e value of piow is determ ined by the constant revenue condition and the offered load (which is independent of the priority settings). Thus, a pricing scheme for a particular configuration is com pletely specified by a priority setting and a value for Phigh- T he first price range is the feasible set of values for phigh such th a t at the optim al priority setting we have 0 < piow < Phigh■ At the low end of this range for phigh, we have phigh — P lo w and thus there is no m onetary incentive to choose low priority service; at the high end of this range we have piow = 0 and all of th e revenue is generated by th e high priority service class. The second price range is th e set of values for phigh such th a t th e pricing scheme is acceptable; for each price in this range, the optim al priority vector d opt (which is listed in th e th ird column) is a Nash equilibrium . T he th ird price range is th e set of values for phigh such th a t th e pricing scheme is adoptable; for each price in this range, all application types have values of U under the priority pricing scheme th a t are higher th an their values of U under th e flat pricing scheme. O ur objective is to find values for phigh and piow such th a t th e priority pricing scheme is both acceptable and adoptable. The m ost im portant result of our sim ula tions is th a t, for each configuration and at each backbone speed (m aking a to tal o f ; 42 separate instances), there is a set of prices th a t is both acceptable and adoptable. I Thus, in each of these configurations, we can always find values for Phigh and piow! such th a t all users are m ore satisfied w ith the priority pricing th an w ith the flat 44 Telnet Voice FT P Email Conf num % % num % % num % % num % % num apps pkts byts apps pkts byts apps pkts byts apps pkts byts 1 2 4.6 0.6 4 24.0 10.7 4 54.9 68.2 5 16.6 20.6 2 3 6.2 0.8 5 27.7 13.0 3 29.6 38.6 10 36.6 47.6 3 3 5.9 0.9 5 42.3 22.5 3 29.3 43.3 7 22.5 33.3 4 3 7.1 1.7 4 22.8 9.5 4 51.8 65.8 5 18.2 23.1 5 3 5.5 0.7 6 27.6 12.8 5 48.6 62.8 7 18.3 23.6 6 6 5.8 0.8 12 29.8 14.2 6 35.5 46.8 12 29.0 38.2 7 9 6.0 1.5 18 31.7 14.0 9 32.3 43.7 18 30.1 40.8 Table 4.9: Aggregate Traffic C haracteristics link spd kbps link util (%) ffop t y o p t y f l a t feasible price range acceptable price range adoptable price range 570 670 1070 1270 2000 5000 88.6 75.4 47.4 39.4 25.2 10.1 2211 2211 2221 2221 2221 2121 109.4 163.5 277.7 288.3 232.3 104.9 -188.3 -26.7 233.2 260.5 224.9 104.8 (0.2681, 2.4802) (0.2681, 2.4802) (0.2681, 0.3381) (0.2681, 0.3381) (0.2681, 0.3381) (0.2681, 0.3856) (0.5501, 1.0417) (0.4792, 0.6429) (0.2724, 0.2964) (0.2705, 0.2898) (0.2682, 0.2742) (0.2681, 0.2682) (0.2757, 1.1307) (0.2798, 0.6868) (0.2736, 0.2987) (0.2711, 0.2831) (0.2683, 0.2686) (0.2681, 0.2682) Table 4.10: Sim ulation Results for Configuration 1. link spd kbps link util (%) ffopt y o p t y f l a t feasible price range acceptable price range adoptable price range 670 870 1070 1270 2000 4000 90.2 70.4 56.9 47.8 30.3 15.1 2211 2221 2221 2221 2221 2221 62.3 195.2 214.2 220.7 174.6 96.2 -334.3 -4.8 119.3 171.8 161.7 95.7 (0.2380, 1.7856) (0.2239, 1.7856) (0.2235, 0.4059) (0.2235, 0.4059) (0.2235, 0.4059) (0.2235, 0.4059) (0.7789, 1.2343) (0.2395, 0.4033) (0.2297, 0.3501) (0.2271, 0.3214) (0.2239, 0.2543) (0.2235, 0.2238) (0.2332, 1.3435) (0.2526, 0.4059) (0.2297, 0.3501) (0.2271, 0.3214) (0.2239, 0.2543) (0.2235, 0.2238) Table 4.11: Sim ulation Results for Configuration 2. link spd kbps link util (%) ffopt y o p t y f l a t feasible price range acceptable price range adoptable price range 670 870 1070 1270 2000 4000 81.4 63.1 51.1 43.0 27.3 13.6 2211 2221 2221 2221 2221 2121 78.3 154.1 198.3 208.5 171.9 95.2 -469.0 -29.2 109.6 166.2 163.3 94.8 (0.2503, 1.1212) (0.2503, 0.3777) (0.2503, 0.3777) (0.2503, 0.3777) (0.2503, 0.3777) (0.2503, 0.5494) (0.5916, 0.8178) (0.2651, 0.3505) (0.2563, 0.3320) (0.2537, 0.3111) (0.2505, 0.2669) (0.2503, 0.2505) (0.2615, 0.9753) (0.2727, 0.3775) (0.2594, 0.3016) (0.2554, 0.2738) (0.2507, 0.2510) (0.2503, 0.2504) Table 4.12: Sim ulation Results for Configuration 3. link spd kbps link util (%) -o p t y o p t y f l a t feasible price range acceptable price range adoptable price range 300 450 650 1050 2000 4000 87.9 60.2 42.1 25.9 13.6 6.8 2211 2211 2221 2221 2221 1121 35.8 189.1 254.8 317.6 242.0 131.1 -270.2 75.4 212.1 296.0 237.1 130.9 (0.2816, 2.5253) (0.2733, 2.5253) (0.2732, 0.3511) (0.2731, 0.3511) (0.2729, 0.3511) (0.2728, 0.4072) (0.6576, 2.4664) (0.4775, 0.8111) (0.2904, 0.3029) (0.2760, 0.2923) (0.2730, 0.2773) (0.2728, 0.2729) (0.3763, 2.5253) (0.3189, 0.8712) (0.2953, 0.3434) (0.2768, 0.2873) (0.2730, 0.2731) (0.2728, 0.2730) Table 4.13: Sim ulation Results for Configuration 4. link spd kbps link util (%) -Opt y o p t y f l a t feasible price range acceptable price range adoptable price range 570 670 1070 1270 2000 5000 78.0 66.4 41.6 35.0 22.2 8.9 2211 2211 2221 2221 2221 2121 84.5 145.1 254.4 257.9 206.0 90.7 -337.5 -134.8 211.9 234.6 201.4 90.6 (0.2094, 1.6068) (0.2048, 1.6068) (0.2045, 0.2662) (0.2045, 0.2662) (0.2045, 0.2662) (0.2044, 0.3129) (0.4722, 0.9920) (0.4187, 0.5685) (0.2091, 0.2241) (0.2067, 0.2191) (0.2046, 0.2078) (0.2044, 0.2045) (0.2240, 1.1045) (0.2203, 0.6193) (0.2106, 0.2341) (0.2074, 0.2201) (0.2047, 0.2049) (0.2044, 0.2045) Table 4.14: Sim ulation Results for Configuration 5. link spd kbps link util (%) a opt y o p t y f l a t feasible price range acceptable price range adoptable price range 570 670 1070 1270 2000 5000 68.4 58.2 36.4 30.7 19.8 7.7 2211 2221 2221 2221 2221 2121 225.6 297.0 378.9 378.9 285.8 120.3 -357.7 -76.7 338.6 340.5 278.0 120.2 (0.1175, 0.8182) (0.1175, 0.1912) (0.1175, 0.1912) (0.1175, 0.1912) (0.1174, 0.1912) (0.1174, 0.2420) (0.4097, 0.5087) (0.1359, 0.1912) (0.1191, 0.1518) (0.1191, 0.1518) (0.1175, 0.1250) (0.1174, 0.1175) (0.1260, 0.5696) (0.1474, 0.1912) (0.1201, 0.1315) (0.1201, 0.1302) (0.1176, 0.1177) (0.1174, 0.1175) Table 4.15: Sim ulation Results for Configuration 6. link spd kbps link util (%) f f °Pt y o p t y f l a t feasible price range acceptable price range adoptable price range 300 400 650 1000 2000 3000 71.0 53.2 32.8 21.3 10.7 7.1 2211 2211 2221 2221 2221 2121 229.6 396.0 654.7 654.0 449.1 310.7 -804.9 -209.5 454.4 594.0 441.8 310.2 (0.0824, 0.5312) (0.0804, 0.5312) (0.0799, 0.1323) (0.0799, 0.1323) (0.0799, 0.1323) (0.0799, 0.1709) (0.4926, 0.5312) (0.3871, 0.5312) (0.0911, 0.1323) (0.0818, 0.1208) (0.0800, 0.0851) (0.0799, 0.0802) (0.1112, 0.5312) (0.1002, 0.5312) (0.0984, 0.1323) (0.0830, 0.0964) (0.0800, 0.0810) (0.0799, 0.0802) Table 4.16: Sim ulation Results for Configuration 7. pricing scheme. Furtherm ore, this priority pricing scheme will induce users, out of their own selfishness, to ask for the service class th a t optim izes th e netw ork’s overall efficiency. T he existence of acceptable and adoptable priority pricing schemes over a wide range of network conditions is encouraging evidence th a t pricing will indeed be an effective m ethod of inducing overall network efficiency. There are also several other interesting aspects to the data. As expected, the op tim al level of overall satisfaction is always higher under th e optim al priority setting th an it is when all applications request high priority service (which occurs when the prices are flat). T he difference between V opt and V*lat decreases as the backbone speed increases (which, because the offered load is kept constant, reduces the u ti lization) because th e scheduling algorithm becomes less im portant as th e network becomes less congested. Thus, the use of a pricing scheme to m axim ize network efficiency is less im portant when th e network is lightly loaded. A related effect is th a t the range of acceptable prices increases as th e utilization increases. W hen the network is heavily loaded, alm ost any pricing scheme th at charges m ore for th e high priority service will induce applications to m ake the ap propriate service class decisions. W hen th e network is only lightly loaded, th e range of acceptable prices is often extrem ely small. However, since the overall efficiency is relatively independent of the priority choices in this case (as indicated by the closeness of V opt and V*lat), there is no significant efficiency loss if th e prices are not w ithin this range. One would expect th a t increasing the backbone speed would always increase the overall level of satisfaction. However, notice th a t in each one of our configurations this expectation is violated; as the backbone speed increases, V opt first increases as expected but th en decreases rath er dram atically. This surprising decrease in V opt is due to dynam ics of the window-based flow control used in TC P, and has nothing to do w ith th e issues addressed in this paper. We clarify this phenom enon as follows. Recall th a t V f t p compares the actual transfer tim e to the ideal transfer tim e, and this ideal transfer tim e is com puted assum ing th a t the flow control algorithm allows the source to fully utilize th e available bandw idth. W hen the backbone speeds are low, the transfer tim e of an F T P application is lim ited by congestion in th e back- 1 bone links; at these low speeds, any increase in th e backbone speed decreases th e j I I I 48 ' congestion and therefore increases V f t p and thus increases V o p t. At high backbone speeds and th e same offered load, there is little congestion (as indicated by the utilization data) and th e achieved throughput rate of an F T P application is lim ited only by th e available bandw idth and the flow control algorithm ’s ability to utilize th a t bandw idth. T he window flow control used in TC P, which in our sim ulations has a m axim um window size of 5000 bytes, results in the transfer tim e reaching a m inim um value th a t is essentially independent of any further increases in th e back bone speed. Thus, any further increase in th e backbone speed m erely decreases the ideal transfer tim e but does not change the actual transfer tim e, thereby decreasing V f t p an-d thus decreasing V o p t. T he Telnet and Voice applications are both real-tim e applications, w ith perfor m ance sensitivities to delays of tenths of seconds. T he Em ail and F T P are much less sensitive to delays. Thus, one m ight have predicted th a t th e optim al priority setting would always be when the Telnet and Voice applications request high pri ority service and th e F T P and Em ail applications request low priority service; in our notation, this selection is th e 2211 priority setting. At th e slowest backbone speeds (the highest network utilizations), this is indeed th e optim al priority setting in all of our netw ork configurations. However, as the backbone speed is increased, th e optim al priority setting changes from 2211 to 2221 in every configuration. At the setting 2221, th e F T P application is requesting high priority service along w ith the Voice and Telnet applications; this priority setting is not optim al at the slowest backbone speeds because, when th e utilization is extrem ely high, th e Telnet and Voice applications cannot tolerate additional high priority traffic w ithout suffering significant perform ance degradation. In six of the seven configurations, at th e high est backbone speed the optim al priority setting had Voice requesting low priority service10; this is because the utilization is low enough th a t no packets violated the Voice delay bound. Also, note th a t in no case is it optim al for Em ail to request high priority service; this reflects the relative delay-insensitivity of this application. 10We assume that this would also have occurred in the remaining configuration (configuration 2) if we had tested a higher backbone speed. Figures 4.4 and 4.5 represent in graphical form the inform ation for Configura tion 1 found in Table 4.10. T he graphical representation portrayed by Configura tion 1 is typical of all the configurations. T he first figure displays th e acceptable price range while th e second figure displays the adoptable price range. In each fig ure, th e dotted vertical line represents th e lower bound on th e feasible price range (the flat price) and the solid vertical line represents the upper bound on the feasible price range (the m axim um high priority price). The num bers to th e right of the solid vertical line identify the optim al service vector for each link utilization using the notation established above. T he y axis lists link utilizations for each run and th e x axis lists th e price per m egabyte of high priority traffic. We notice th a t the acceptable and adoptable price spaces narrow and move to the left as th e link utilization decreases. This effect occurs because there is less differen tiatio n betw een th e service classes as network congestion decreases, constraining the price spaces, which is precisely the m echanism the priority scheme exploits. We also notice th a t th e price spaces approach b u t do not drop below the lower bound of the feasible price range. Recall th a t the lower bound of the feasible price range equals th e flat price. We know th a t th e lower bound on application perform ance for the highest quality service occurs when all users sim ultaneously select th e highest qual ity service because all user classes com pete equally for network resources, i.e. w ith th e 2222 priority setting. Users are assessed the flat price only when all applications select th e highest quality of service. Therefore, it follows th a t the lower price space bound for high priority service will never drop below the flat price because the high priority service perform ance m etric will never degrade below th e same high priority service perform ance m etric in the FIFO run. Table 4.17 contains th e service discipline distribution for Y%= i V % as a function of th e service vector, < ? , and link utilization. At higher link utilizations th e distribution of sums of service distributions is disperse. As expected the distribution becomes uniform as link utilization decreases, due to the decrease in netw ork congestion. T he d a ta presented in this section shows th a t the range of acceptable and adopt able priority prices depends on the netw ork topology, th e backbone speeds, and the offered load. In order for our paradigm , in which prices are used to elicit efficientj network utilization, to be applicable to real com puter netw orks, we m ust assume' Link Util Link Util lOO 1 2 2 1 1 2 2 1 1 50 - 2221 2221 2221 — max hi price • • • • flat price 2121 1.5 2 2.5 0.5 1 O High Priority Price per Megabyte Figure 4.4: A cceptable Price Range for Configuration 1. 1 0 0 75 25 O O « 5 2 2 1 1 221 1 t I 2221 2221 2221 2 1 2 1 — max hi price • • • • flat price i — 2 0.5 1 1.5 2 2.5 High Priority Price per Megabyte Figure 4.5: A doptable Price Range for Configuration 1. 51 ff opt link util 2211 88.58 2211 75.35 2221 47.35 2221 39.82 2221 25.24 2121 10.10 1112 -221.80 -47.56 199.87 231.05 220.32 104.81 d 1121 -1148.77 -488.11 33.41 105.11 219.57 104.89 s i 1122 -2387.86 -894.25 -73.59 35.70 203.79 104.80 e s 1211 106.05 161.89 246.08 262.24 224.89 104.82 r c 1212 74.12 143.20 238.93 256.32 221.86 104.81 v i 1221 -1366.92 -291.44 217.32 254.52 231.50 104.88 i p 1222 -3006.80 -839.94 154.29 218.18 223.70 104.82 c 1 2111 -185.03 -25.12 233.46 260.65 224.91 104.82 e i 2112 -211.04 -41.86 201.28 231.89 220.35 104.81 n 2121 -481.91 -232.32 83.20 136.53 220.55 104.89 e 2122 -995.09 -482.67 -3.95 74.26 205.17 104.80 2211 109.38 163.50 246.33 262.34 224.90 104.82 2212 84.81 148.96 240.39 257.24 221.89 104.81 2221 -16.50 116.94 277.65 288.30 232.34 104.88 2222 -188.30 -26.70 233.23 260.54 224.90 104.82 Table 4.17: Service Discipline D istribution for Configuration 1. th a t th e adm inistrative body th a t sets the prices can m ake, on th e basis of historical evidence (and perhaps m arket research), sufficiently accurate predictions of th e of fered load. There is a precedent for this; in the telephone netw ork, th e offered load is reasonably well characterized[45]. We expect th a t in the fu tu re internetw orks, the aggregate traffic load will be so large th a t a statistical characterization will yield reasonably accurate predictions. 4.4 Conclusion T he priority pricing literatu re in economics has shown th a t in th e context of a simple m odel of allocation of a nonstorable good w ith fluctuating supply and constant dem and, there are certain priority pricing schemes th a t can m ake everyone b etter i off, w hen com pared to a flat pricing scheme [70]. j In this chapter we have exam ined th e role of pricing policies in m ultiple service class networks. We have argued th a t some form of service-class sensitive pricing was required in order for any m ulticlass service discipline to have th e desired ef fect. We then presented an abstract form ulation of service disciplines and p ric in g ! policies. This form ulation allowed us to m ore clearly describe th e interplay between 52 service disciplines and pricing policies. Effective m ulticlass service disciplines al lowed networks to focus resources on the perform ance sensitive applications, while effective pricing policies allowed us to spread th e benefits of m ultiple service classes around to all users, rath er than ju st having these benefits rem ain exclusively w ith th e users of applications which were perform ance sensitive. Finally, we illustrated some of these concepts through sim ulation of several sim ple exam ple networks. In our sim ulations, we found th a t it was possible to set the prices so th a t users of every application type were m ore satisfied w ith the combined cost and perform ance of a netw ork w ith service-class sensitive prices. For some application types the perfor m ance penalty received for requesting a less-than-optim al service class was offset by th e reduced price of the service. For the other application types th e m onetary penalty incurred by using th e m ore expensive, higher quality service classes was offset by th e im proved perform ance they received. On one level our conclusions are hardly surprising. Offering m ultiple service classes and charging differently for them is an obvious idea, and is certainly not new w ith us. However, it is a crucial idea th a t needs to be m ore fully explored. We expect th a t w ith service-class insensitive pricing, user behavior will render the netw ork equivalent to a single service class network. We then th in k one of two outcom es is likely. One possibility is th a t th e quality of service will not be high enough to support dem anding applications like real-tim e video or voice, and the only viable applications will be like those on to d ay ’s Internet. T he other likely outcom e is th a t, by over-engineering the netw ork, th e quality of service will be quite high, b u t so will th e prices, and only the m ost quality conscious users will consider the cost worthwhile. In both cases, the technical achievem ent of integrating applications w ith different qualities of service requirem ents in one netw ork m ay be undone by the econom ic forces th a t segment the m arket. 53 Chapter 5 Interplay Between Price and Congestion A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. — Lucius Annaeus Seneca T he notion of utility is extrem ely im portant when trying to quantify user preference[50, 67]. It requires the construction of u tility functions th a t capture th e essential characteristics or attrib u tes of the decision problem under considera tion. We m ake use of the utility function m odel constructed in C hapter 4 where each function consisted of two attributes: network perform ance and cost. T he first a ttrib u te , netw ork perform ance, degrades w ith increasing levels of netw ork conges tion. T he second a ttrib u te of utility, cost, degrades as a function of increased price. We weight and scale th e relative values produced by th e netw ork perform ance and cost attrib u tes so th a t the dynam ic ranges have sim ilar m agnitudes and construct our u tility functions using a sim ple additive model. We discuss th e interplay betw een price and congestion by fixing the link capacity and netw ork operating cost, and then varying th e num ber of users. We analyze changes in to tal utility. N aturally, higher levels of netw ork utilization are desirable} so th a t greater social welfare can be received by th e user com m unity at large. W hen; to tal operating costs are fixed, higher netw ork utilization im plies lower average cost | to individual users. However, as w ith any resource, excessively heavy utilization leads to inefficient allocation strategies for th e user population as a whole, thereby, benefiting relatively few users, if any at all[28]. Individual users also prefer lower levels of congestion because it m axim izes their individual perform ance. It follows th a t a careful consideration of the interaction of price and congestion is w arranted. 5.1 Problem Statement and System Model In describing th e interaction of price and congestion in com puter networks, we are prim arily interested in addressing th e following question: How does this interplay affect th e user’s utility? We are concerned about two effects. F irst, if applications are highly sensitive to variations in price and congestion, then even small changes in th e num ber of users will yield entirely new network dynam ics. Second, we are interested in each application’s ability to sustain a m inim um Quality of Service (QoS) benefit, b. This ability allows us to specify a price range and m inim um level of service for each application. T he notion of benefit is m ore fully described below. T he sim plest m eans by which to m easure the interaction betw een network con gestion and cost is to exam ine networks w ith only one type of user. In this simplified netw ork setting, th e effects of congestion are not obscured by other application types. Also, if all users of a given application type have th e same traffic generation p atterns, th en m easurem ents are further simplified because the m arginal traffic increm ent is constant. T h at is, each new user adds an identical am ount of traffic to the networks to tal offered load. This point is crucial to subsequent analysis because while the m arginal traffic increm ent m ay be linear, th e effect on netw ork perform ance is by no m eans linear. The im pact of adding a new user my be inconsequential when th e user population is quite small; however, this im pact can be quite substantial w hen th e user population becomes m oderately large for a fixed netw ork capacity. W hile th e analysis m ay be sim pler, th e draw back of this approach is th a t it fails to cap tu re th e interaction betw een application types, which has a nonlinear m arginal traffic increm ent; however, this interaction was the prim ary focus of C hapter 4. 55 In order to describe the interplay between congestion and cost, we define two functions. Let th e first function, P (n ), denote a price curve which is a decreas ing, convex function. P (n ) holds to tal revenue constant and reflects th e price per m egabyte (MB) as a function of the to tal num ber of users, n. T he second function, A vgU (n ), denotes th e users average u tility where utility is dependent on netw ork perform ance and cost. As m entioned above, average cost decreases along a convex curve w ith th e num ber of users. In our netw ork m odel, th e rate of perform ance degradation increases along a convex curve w ith the num ber of users. Therefore, these variables have polar effects. T h at is, users prefer a lower cost th a t occurs w ith a higher num ber of users1; however, users also prefer lower service degradation th a t occurs w ith a lower num ber of users. Given the n atu re of these two inputs and th e fact th a t our utility function is m onotonic, i.e. m ore is b etter th an less, th e average u tility curve will be parabolic and concave.2 We discuss th e usefulness of each of these functions below. O ur analysis exam ines th e average user’s utility as opposed to th e sum of all users because of th e underlying assum ptions im posed in form alizing our cost and perform ance functions. We need to consider th e average per user quantities of cost and perform ance for the following reasons. F irst, we hold netw ork operating cost constant; therefore, sum m ing th e cost allocated to the individual users would be a constant when considering to tal cost irrespective of the num ber of users. Hence, an analysis considering only to tal utility obscures th e interaction of price and congestion for an individual user. Second, we need to look at average per user perform ance because th e sum of our perform ance m easures gets b etter, i.e. degrades less, as th e num ber of users decreases. This statem ent rem ains tru e even if th e individual user’s perform ance rem ained constant when the num ber of users decreased because 1This statem ent remains true for any finite good with a fixed cost. 2Perhaps this statem ent warrants clarification. The basic utility function is utility = perfor-\ mance + cost. However, larger performance and cost values are detrim ental to the user’s utility so we negate these inputs. The actual utility function becomes utility = -performance - cost; there fore, the utility function m onotonically decreases in the inputs. Due to the negation of the input variables, we can still say that more is better than less and that the resulting average utility curve will be parabolic and concave. I there would be a smaller num ber of users contributing to th e perform ance sum .3 Therefore, we need to consider average per user perform ance because we are m ost interested in evaluating how the aggregate traffic load affects an individual user’s perception of perform ance. Average utility curves characterize each individual’s satisfaction w ith network service as a function of perform ance and price. We assum e th a t each application has a m inim um QoS level b. Given th e perform ance m easures, which are dependent on th e level of congestion present at various network utilizations, we define price ranges such th a t each user has a positive benefit, i.e. th e com bined function of price and perform ance is greater th a n b. More precisely, if A vg U (n ) is th e user’s average utility function, a positive benefit will occur wherever A vg U (n ) > 5, for some benefit b. We only touch upon th e notion of benefit and do not delve into it deeply because it is difficult to assess th e precise value th a t a user places on a particular service. Such a topic is th e focus of utility and decision theorists[54, 64, 67]. 5.2 Simulation Environment O ur study exam ines th e effects of increasing cost and decreasing perform ance on th e user’s satisfaction w ith netw ork service. T he price curve is a contrived input showing how changes in th e num ber of users correspond to changes in price. The values obtained from this curve are used in conjunction w ith th e perform ance values (obtained from sim ulation) to elicit average utilities. These perform ance values are held constant when studying changes in average utility. Changing th e network operating cost or num ber of applications alters th e price curve. These m odifications can alter significantly the shape of th e average utility curve, thereby, drastically affecting th e user’s satisfaction. Before we begin our analysis, there are two im portant observations we would likei to m ention regarding th e netw ork operating cost. First, as th e netw ork operating! cost goes to infinity the highest average utility occurs w ith th e highest num ber oft users because th e cost is am ortized over a greater num ber of users irrespective of J 3This assertion covers the worst case, i.e. if performance did noi degrade as the number of; users increased. However, as indicated in the previous sentence, in reality network perform ance1 measures degrade with the number of users. I I I 57 how degraded network perform ance becomes. On the other hand, as the network operating cost goes to zero th e highest average u tility occurs w ith th e lowest num ber of users because there is no contention for resources and th e lone user(s) is able to a tta in the b ette r average perform ance w ithout regard to cost.4 Second, changing th e operating cost does not change the shape of th e price curve,5 it m erely changes th e per byte charge which affects all users equally. O ur study of price and congestion covers four types of networks separately. We exam ine networks w ith all Telnet applications, all Voice applications, all F T P applications, and all Em ail applications. In each instance, th e netw ork topology consists of two switches connected by one bottleneck link (see Figure 4.1). The m axim um num ber of users is chosen to satu rate th e bottleneck link. T he num bers of users in each configuration is decrem ented by an integer step variable until a netw ork configuration of one or two users rem ains. T he link speed is norm alized to reflect th e aggregate traffic load generated by each application type and is held constant while th e num ber of users decreases. Each tim e the num ber of users decreases, th e price per byte charged to the users increases because in each configuration we hold the netw ork operating cost constant. T he operating cost requires norm alization w ith respect to the aggregate traffic load, which is a function of the num ber of users for each application type, so th a t th e effect of pricing is consistent betw een applications. This step enables us to com pare and contrast the interaction betw een netw ork congestion and cost among th e four application types. T he perform ance m easures are scaled to the sam e order of m agnitude as the network operating cost so th a t both a ttrib u tes in th e u tility function, perform ance and cost, play an equally representative role in th e user’s average utility. For the purpose of this exam ple, we set th e netw ork operating cost at 100 for both th e F T P and Em ail configurations since these applications have nearly identical aggregate traffic levels. T he norm alized netw ork operating costs for th e Telnet and Voice configurations becom e 16 and 42 respectively. 4The average performance values are relatively flat when the number of users is small; therefore, we can consider these cases relatively equivalent in terms of average utility. 5This statem ent remains true as long the operating cost, D, is greater than zero. 1 num ber of users link util num ber of bytes price per m egabyte Y ,V A v g V AvgU 30 98.31 66359800 0.241109829 2052.34 68.41 -68.94 28 92.33 62325250 0.256717783 204.38 7.30 -7.87 26 84.85 57272950 0.279363993 69.51 2.67 -3.29 24 77.12 52056700 0.307357170 30.58 1.29 -1.94 22 71.34 48153850 0.332268344 16.45 0.75 -1.48 20 65.91 44490000 0.359631378 13.47 0.67 -1.47 18 58.73 39640400 0.403628621 9.84 0.55 -1.44 16 52.15 35203800 0.454496390 8.21 0.51 -1.51 14 45.24 30536450 0.523963984 6.66 0.48 -1.62 12 39.17 26438650 0.605174621 5.59 0.47 -1.80 10 32.38 21854700 0.732107968 4.58 0.46 -2.06 8 25.70 17344450 0.922485291 3.60 0.45 -2.45 6 19.97 13481800 1.186785147 2.70 0.45 -3.12 4 13.04 8803900 1.817376390 1.79 0.45 -4.45 2 6.63 4476000 3.574620197 0.88 0.44 -8.44 Table 5.1: Telnet Norm alized N etwork O perating Cost Analysis 5.3 Data and Analysis Tables 5.1-5.4 contain th e results of the norm alized netw ork operating cost analysis for th e Telnet, Voice, F T P , and Em ail applications respectively. Each table contains th e following inform ation: num ber of users, link utilization, aggregate traffic in bytes, price per m egabyte (M B), sum of th e perform ance m easures (Yl V ), average perform ance m easure (A v g V (n )), and average utility (A vg U (n )). The d ata can also be viewed in Figures 5.1-5.4. Each application type has two figures, both are functions of the num ber of users. T he first figure contains th e price curve while the second displays th e average u tility verses link utilization. T he highest average utility for th e Telnet, Voice, F T P , and Em ail configurations occurs at link utilizations of 58.73%, 46.05%, 44.44%, and 90.18% respectively. T he relative flatness of th e Telnet average utility function indicates th a t the rate of change between perform ance and cost is relatively constant and th a t a smaller] change in cost will shift the point of highest average utility. E m ail’s highest average' u tility occurs at the extrem ely high utilization of 90.18% indicating th a t these users! 59! ____i num ber of users link util num ber of bytes price per m egabyte A v g V AvgU 20 87.58 177348780 0.236821477 1486.17 74.31 -76.41 18 80.50 163014480 0.257645824 878.87 48.83 -51.16 16 74.35 150561360 0.278956035 509.41 31.84 -34.46 14 65.42 132474420 0.317042339 163.66 11.69 -14.69 12 55.76 112920300 0.371943751 34.25 2.84 -6.35 10 46.05 93244680 0.450427842 3.12 0.31 -4.51 8 36.58 74081160 0.566945766 1.97 0.25 -5.50 6 26.20 53059860 0.791558817 1.08 0.18 -7.18 4 18.05 36559620 1.148808439 0.70 0.18 -10.68 2 8.57 17350200 2.420721375 0.35 0.17 -21.18 Table 5.2: Voice Norm alized Network O perating Cost Analysis num ber of users link util num ber of bytes price per m egabyte £ V A v g V AvgU 7 99.99 423680400 0.236026967 53.31 -7.62 -6.67 6 88.35 373925750 0.267432772 178.50 -29.75 13.08 5 75.92 321322200 0.311214102 208.04 -41.61 21.61 4 61.96 262217550 0.381362727 216.13 -54.03 29.03 3 44.44 188081250 0.531685109 209.20 -69.73 36.40 2 30.93 130897900 0.763954196 158.54 -79.27 29.27 1 16.06 67982750 1.470961384 90.94 -90.94 -9.06 Table 5.3: F T P Norm alized Network O perating Cost Analysis num ber of users link util num ber of bytes price per m egabyte T .V A v g V AvgU 14 99.99 423680400 0.236026967 429.38 30.67 -37.81 12 90.18 381645100 0.262023540 14.25 1.69 -9.52 10 75.17 318128800 0.314338092 5.63 0.56 -10.56 8 59.57 252135450 0.396612218 3.02 0.38 -12.88 6 45.89 194214350 0.514895012 1.71 0.29 -16.95 4 31.63 133846350 0.747125342 0.94 0.24 -25.23 2 15.61 66048400 1.514041218 0.37 0.19 -50.19 Table 5.4: Em ail Norm alized Network O perating Cost Analysis P rice p e r Megabyte Telnet Price Curve Telnet Utility Function Curve 4 3 2 1 0 N um ber o f Users \ link util *■ -. avg utility 100 7 5 - 50 2 5 - -2 5 - -50 - -75 N um ber o f U sers Figure 5.1: Telnet Price Curve and Average U tility Function V oice Price Curve Voice Utility Function Curve \ link util * * * . avg utility 90 60 30 -30 -60 -90 20 24 N um ber o f Users 2.5-1 1.5 0.5 - 20 24 N um ber o f U sers Figure 5.2: Voice Price Curve and Average U tility Function FTP Price Curve FTP Utility Function Curve \ link util '* > . avg utility 100- 87.5 - 7 5 - 62.5 - 5 0 - 37.5 - 2 5 - 12.5 - - 12.5 7.5 1.5 - 1.3 5 - 1.2 - u 1.05 ■ X ) §> 0 .9 - I ° '7 5 ' 8 0.6 - & 0 .4 5 - 0 .3 - 0 . 15 - 4.5 7.5 1.5 Num ber o f U sers N um ber o f U sers Figure 5.3: F T P Price Curve and Average U tility Function Email Price Curve Email Utility Function Curve \ link util avg utility 100-1 8 0 - 6 0 - 4 0 - 2 0 - -20- - 40 - -60 1.4 - & 1.2 - s g, 0.8- 0 1 0.6- 0 .4 - 0.2 Num ber o f U sers N um ber o f U sers Figure 5.4: Em ail Price Curve and Average U tility Function application type A vgU opt link utilization D norm D range std dev of Dnorm absolute of D norm Telnet 58.73 16 (5,18) (-0.69,+0.13) 0.82 Voice 46.05 42 (3,152) (-0.93,+2.62) 3.53 F T P 44.44 100 (58,188) (-0.42,+0.88) 1.30 Em ail 90.81 100 (38,2476) (-0.62,+23.76) 24.38 Table 5.5: U tility Analysis are insensitive to perform ance and m ost sensitive to a low price. Voice and F T P exhibit nearly perfect concave parabolic curves w ith an absolute m axim um at ap proxim ately 45% utilization. Shifting th e point of highest average utility, AvgU opt, will require larger variations in price. Table 5.5 contains th e results of th e price and congestion analysis. T he table contains th e following inform ation: th e application type, link utilization yielding the A vgU opt, norm alized netw ork operating cost (Dnorm), range of network operating costs yielding th e same point of AvgU opt (D range), th e range in standard deviations of D norm yielding th e same AvgU opt,6 and the absolute num ber of standard devia tions. T he last colum n contains th e m ost pertinent inform ation because it provides each application’s relative m easure of price sensitivity in term s of changes in the norm alized netw ork operating cost. A smaller num ber indicates greater sensitivity tow ard changes in price. We next relate the results in Tables 5.1-5.4 to those found in Table 5.5. Telnet is m oderately sensitive to price and perform ance betw een link utilizations of 71% and 20%. Average utility rem ains relatively constant during this interval because th e effect of increased price brought about by decreasing th e num ber of users is nearly equal to th e perform ance im provem ent th a t occurs during this in- [ terval. Above 71%, Telnet is increasingly perform ance sensitive due to increased! netw ork congestion. Below 20%, Telnet is increasingly price sensitive because the| cost increases while th e perform ance gains approach zero. For Voice, perform ance gains are nearly zero until the link utilization reaches 46%. It follows th a t the! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - j 6 We assume that network operating cost,D , is greater than or equal to zero; therefore, lower' bound for the standard deviation of D norm is -1.0. 63 lower price elastic bound occurs at -0.93 standard deviations (close to th e absolute lower bound of -1.0) because netw ork operating cost can be absorbed by a larger num ber of users w ithout a perform ance im pact. Above 46% perform ance degrades m uch m ore rapidly so a higher cost, resulting from a higher upper price elastic bound of +2.62 standard deviations, can be absorbed w ithout decreasing th e Voice user’s A v g U . F T P ’s perform ance m easure degrades at a m oderately constant rate; therefore, F T P is m oderately sensitive to changes in price as seen by its somewhat sm aller stan d ard deviation range holding average u tility constant. N either a de crease in cost brought about by lowering the netw ork operating cost in conjunction w ith a relatively flat perform ance m easure, nor a large increase in cost brought about by a rapid degradation of perform ance can be accepted w ithout changing A vgU opt. E m ail’s upper price elastic range, +23.76 standard deviations, is highly influenced by th e boundary occurring at the vastly over utilized link of 99.9%. At such a utilization, Em ail users experience extrem ely poor perform ance; therefore th e A vgU opt point can incur an exorbitant price w ithout causing A vgU opt to shift upw ard. T he lower bound on price is quite low because E m ail’s perform ance m ea sure does not degrade rapidly even at the relatively high link utilization of 90%; therefore, A vgU opt is kept high by lower cost th a t accom panies a larger num ber of users. 5.4 Benefit Analysis T he above discussion says little about th e value th a t th e user places on network service, where network service is a function of network perform ance and cost, i.e. th e user’s u tility.7 U nderstanding th e users perception of utility can be aided by incorporating th e notion of a QoS benefit, 6, alluded to above. We exam ine the interplay betw een price and congestion where a positive user benefit occurs wher-J ever AvgU > b. T he constant, b, will differ for each application (and individual! user). This difference occurs for three reasons. F irst, each application has a dif-j ferent perform ance m easure; therefore, norm alization is required. Second and morel I _ _ 1 7We should reiterate that a formal study of value is not the thrust of this research. We raise the issue as an area for future work. application type ^ n o r m positive benefit price range Telnet Voice F T P Em ail -0.40 -1.24 10.00 -2.62 (0.31,0.62) (0.40,0.60) (0.36,0.82) (0.26,0.37) Table 5.6: Price Range Benefit Analysis im portantly, some application classes require a higher level of service delivered by th e network; therefore, a greater benefit m ay be required. Finally, users w ithin a p articular application class will have different valuations of netw ork service. We provide a brief exam ple for one such valuation below. Table 5.6 contains th e results of th e benefit analysis. It contains the following data: the application type, norm alized benefit (bnorm), and positive benefit price range. To illustrate benefit analysis, we chose an arb itrary benefit for one of the applications and then determ ine an equivalent benefit for the rem aining applications. The equivalent benefit is calculated by norm alizing th e arb itrary benefit w ith respect to A vgU opt for each of the rem aining applications. We select an arbitrary benefit for F T P to occur 10 units below A vgU opt. Therefore, b = 10, which produces a positive benefit wherever AvgU > 36.4 — 10 = 26.4. This benefit roughly relates to F T P consuming an equivalent bandw idth betw een 33% and 70% of to tal link capacity. T he norm alized benefits for Telnet, Voice, and Em ail are -0.40, -1.24, and -2.62 respectively. T he positive benefit price range gives the price range over which a positive benefit occurs. A m ore comprehensive treatm en t of benefit would include an adjustm ent of th e norm alized benefits to reflect th e relative im portance of the individual applications to prospective users. This adjustm ent correlates to the value th a t users places on particular services, hence we defer such an analysis and present only the above framework. Em ail and Voice have the sm allest positive benefit price ranges; therefore, from a benefit perspective, these applications are the m ost sensitive to changes in price. Em ail requires a low price in order to retain its positive benefit. Voice m andates i i good service which is indicative of its narrow price range in a higher priced region, j 65 i . . J Telnet has a broader price range when com pared to Voice. T he broader price range indicates th a t Telnet can not only accept a higher price while obtaining good service b u t can also accept a lower quality service coupled w ith an inexpensive price. F T P exhibits th e largest price range. It can pay top dollar for exceptional service or be content w ith a lower quality service at a lower price. 5.5 Conclusion This chapter studied the interaction betw een network congestion and cost. We were prim arily interested in how this interaction affected the user’s utility. O ur study covered four types of networks separately: a Telnet application netw ork, a Voice ap plication netw ork, an F T P application netw ork, and an Em ail application network. T he four netw ork types were studied separately so th a t the effects of pricing and congestion were not obscured by the interaction among various application types. A lthough this interaction was not the focus of this chapter, it was th e prim ary focus in our m ultiple service class network m odel from C hapter 4. Telnet was found to be th e m ost sensitive to changes in price and congestion. T h at is, th e optim al point of average utility, A vgU opt, shifted for small changes in price. For th e Em ail application, A vgU opt occurred at th e extrem ely high link utilization of 90%. This result was indicative of an Em ail user’s desire for a lower priced service while at th e same tim e dem onstrating insensitivity to perform ance. F T P and Voice were m oderately sensitive to changes in price and congestion; how ever, a Voice user’s perform ance m easure was found to degrade rapidly once the offered load exceeded a critical threshold (approxim ately 70% link utilization). In th e benefit analysis we learned th a t Em ail and Voice m andated th e tightest price ranges in order to m aintain a positive benefit to th e end user, i.e. m eet its user im posed QoS requirem ent. Telnet exhibited a slightly wider price range while F T P ' had th e largest price range. T he average u tility curve characterized an individual’s satisfaction w ith netw ork j service as a function of perform ance and price. T he results of our study were not inconsistent w ith w hat one m ight expect, th e analysis supports the hypothesis th atj th e essential characteristics of the various netw ork services were captured. : Chapter 6 Increased Utility Through Charging Nothing ever becomes real till it is experienced— even a proverb is no proverb tilt your life has illustrated it. — John Keats Pricing has not been critical in to d ay ’s Internet largely due to th e single class of service (best-effort) and extensive governm ent subsidy. Typically institutions are charged for access to regional networks. The access fees are not based on the volume of traffic sent b u t are charged by d ata pipe size, and in m ost cases the charges are not passed back to individual users. W ithin th e netw ork user com m unity, the issue of pricing is viewed as an extrem ely sensitive topic. Any m ention of an alternate pricing policy is sure to face stiff criticism . And we certainly w ant to avoid very costly charging m echanism s as well as those th a t will inhibit usage. M any com pelling argum ents have been m ade for adopting some type of usage I sensitive pricing in internets[17, 22].1 Usage sensitive pricing attem p ts to increasej overall network efficiency by placing users in control of a feedback m echanism (will ingness to pay th e established price) th a t will at tim es signal users not to use the network. T he price gives users an incentive to avoid p u ttin g the netw ork into a 1 Prices m ay be in terms of a monetary substitute, such as a quota system or some other1 adm inistrative mechanism. . I 67! congested state. Econom ists have long argued th a t any scarce resource shared by a large group of self-interested users, requires some form of usage sensitive incen tive stru ctu re to discourage overuse[28]. However, criticism against adopting usage sensitive pricing in th e network com m unity claims th a t such a policy m akes budget forecasting difficult and makes th e com m unity uneasy since costs passed back to end users m ay overly inhibit usage. At the sam e tim e we m ust avoid costly accounting and recovery practices, such as found in th e telephone industry, which account for a large portion of th e bill. 6.1 Problem Statement and System Models In this chapter we exam ine w hether using a sim ple usage sensitive pricing policy increases a user’s utility. We analyze two cases. F irst, we study u tility in a free netw ork. Second, we incorporate a charge and study th e subsequent effects on user utility. We analyze two netw ork models. T he first m odel consists of simple reservation oriented, single and m ultiple class, networks; while the second m odel consists of m ultiple class, reservationless, networks. In th e first m odel we im plem ent an elastic dem and function where offered load is a function of price. T he charge serves to tu rn back a fraction of th e population w ith lower benefits (i.e. cause them to choose not to use the netw ork) so th a t users w ith higher benefits experience less delay in obtaining netw ork service, thereby, experiencing increased utility. In th e second m odel, we hold offered load constant and vary th e d ata pipe size. In this m odel th e charge provides users an incentive to select th e priority m ost appropriate for th eir application. The objective in both models is to specify th e conditions in which charging increases utility. If it can be shown th a t under certain conditions charging increases ones utility, th en charging per se is not som ething th a t should be shunned.. Sections 6.2 and 6-3 define our reservation oriented and reservationless network models. These sections are intended to illustrate our models in th eir m ost general forms. These models can be applied to an array of underlying netw ork models, 6 8 : ___| adm inistrative policies, and end-user environm ents. We present analytical and sim ulation results using several specific netw ork and end-user models in th e respective Sections 6.2.1.1, 6.2.2.2 and 6.3.1. 6.2 Reservation Oriented Network Model In the reservation oriented network m odel we exam ine charging in th e context of adm ission control where user dem and is a function of th e price paid for network service. O ur netw ork m odel is not specific to any particular admission control policy. We could have easily adopted th e adm ission control policies proposed in [25, 30, 52]. We assum e th a t th e netw ork is capable of m aking Quality of Service (QoS) guarantees. W hen a user makes a resource request, th e adm ission control scheme evaluates w hether th e current request can be accepted while m aintaining its prior service com m itm ents. Based on th e results of this query, the netw ork either accepts or rejects the resource request. Once the netw ork accepts a request, it is guaranteed for th e duration of the connection. If the netw ork rejects a request, then the user can either resubm it th e request at a later tim e or wait in th e hopes th a t th e service will becom e available in th e near fu tu re.2 The reservation oriented netw ork m odel uses an arb itrary u tility function con sisting of three attrib u tes: 1) a benefit, 2) a netw ork service cost, and 3) a queueing delay. T he benefit reflects the positive utility th a t a user realizes through gaining access to th e network. For a given user th e precise benefit is unknown so for the purpose of this study, the benefit is selected random ly from a distribution. The cost reflects the price a user m ust pay to utilize th e netw ork, while the queueing delay reflects th e w aiting tim e the user experiences before gaining access. T he basic utility function becomes: U tility = benefit — cost — w aiting (6-1) 2For the sake o f com pleteness, we should add that the user can also wait for a period of tim e and then give up. We analyze this case in the context of sim ulation. We begin w ith a free network where user requests arrive according to a poisson process.3 It is understandable th a t in the absence of some m ethod to filter users, th e average queueing delay will be of concern for m any users. This reasoning is analogous to a phone com pany establishing no rate for using its service. If th e rates were extrem ely low, perhaps free, then lengthy delays would result in relatively few users gaining access to the phone network. The only users receiving a benefit from placing a call would be those who actually obtain netw ork service; therefore, m any users could be forced to wait a very long tim e w ithout ever obtaining access to the netw ork. We m ake a distinction betw een two groups of users: prospective users and actual users. Prospective users are th e group of users who intend to place a call. A ctual users are th e group of users who actually place a call. Let T* denote th e set of prospective users and let A denote the set of actual users. Given these definitions we know V 3 A . Prospective users are assigned a random benefit from a given distribution each tim e they wish to m ake resource requests. They are also given a cost reflecting the price required to place the call. We assum e th a t users will only place a call if th e benefit, b, is greater th an the cost, c. If b < c, th en they would not receive a positive benefit from placing the call because th e cost is too high. In this case we assum e th a t they choose not to use th e netw ork and are assigned a zero utility. In this instance we say th a t th e users are b e tte r off not placing the call. Given a finite V and the benefit and cost for an arb itrary user x denoted by bx and cx respectively, then A = {x : x £ 7* A bx > cx} . Therefore, as c increases \A\ decreases. T he net effect of increasing c is to filter out some portion of th e arrivals in th e free network. Let A0 equal th e poisson arrival ra te in the free netw ork and let Ac equal th e arrival rate in th e cost network. If the probability density function (p.d.f.) for th e benefit distribution b equals f(x ), then arrival rate for a network w ith cost c can be w ritten as Ac = A < , / c °° f(x )d x , and is still poisson. Before introducing th e queueing m odels, we briefly explain the notion of revenue I redistribution in our reservation oriented network. Consider th e user population! I 3 A plausible model might argue that in a free network, the arrival rate should be set arbitrarily , high such that the traffic intensity (the mean arrival rate divided by the mean service rate) is near I j 1.0. However, our subsequent analysis shows that under certain conditions the arrival rate could be set very low. ' 70 as represented by a common pool of utility. W hen users benefit from using the netw ork they m ake a contribution to this pool. By charging users a fee, we extract some portion of th eir utility from this pool. However, th e user population receives an external benefit because a fraction of users w ith lower benefits are tu rn ed away, allowing users who gain access to receive b e tter perform ance, and hence a higher net utility. If we retu rn a portion of the revenue (possibly th e entire sum) extracted from th e pool, we actually increase th e populations’ benefit by the am ount of the redistribution. This general form of redistribution relieves us from having to consider th e difficult problem of establishing an incentive-neutral scheme, which would be required if an actual redistribution policy were im plem ented. We consider th e issue of revenue generation and redistribution in Sections 6.2.1, 6.2.2 and 6.3.1. 6.2.1 Q u eu ein g M od els For a single service class netw ork we m odel this system as a single M /M /n queue. T he arrival rate and service rate are represented as exponentially distributed random variables w ith m eans A and fj, respectively, n defines th e lim its of th e admission control policies; therefore, at m ost n users m ay sim ultaneously gain access to the netw ork while m aintaining the existing QoS com m itm ents. We consider two types of M /M /n queueing models: naive and predictive. In the first m odel, we assum e users cannot predict the delay prior to subm itting requests. In th e second m odel, we assum e users can precisely predict th e expected delay prior to subm itting requests. T he second m odel allows th e users an opportunity to w ithhold th eir requests if th e expected delay is too long, thereby, decreasing th e arrival ra te th a t in tu rn decreases the delay. T he first m odel has no notion of expected delay; therefore, the user m ust actually experience th e delay and cannot w ithhold their requests. In both the naive and predictive models, we can evaluate utility for an individual! or for a population. T he difference betw een these two cases involves how th e benefit, j 6, is derived. For an individual, we assum e th e person knows the benefit obtained j through placing a call, i.e. users call their boss, spouse, insurance adjuster, etc. T he expected benefit becomes this fixed value. For th e user population, th e precise; I benefit is not known. In this case, we set the benefit equal to th e expected value; from the benefit distribution for which b > c, i.e. the expected benefit is filtered by th e cost. E quation 6.1 gives th e form ula for the basic utility function. We define the function U(p) as th e utility function for an M /M /n queue w ith th e traffic intensity, A T he average utility can be rew ritten as: 71/X U(p) = ------- — u w ait(p ) (6.2) t1 where b is th e benefit per second, c is th e cost per second, A equals th e average call duration, w ait(p) denotes th e average w aiting tim e in th e queue calculated w ith traffic intensity p , and w is an arb itrary constant on th e w aiting term . T he constant on th e w aiting term represents a user’s sensitivity to waiting. A higher value should be given to users who are m ore sensitive to delay. N ote th a t w is not a m anipulatable param eter for th e netw ork adm inistrator. It is a param eter set by th e user or user’s application. We consider the im plications of adjusting th e constant on th e waiting term during th e analysis discussion in Section 6.2.1.1. R ath er th an analyzing average utility, identified in E quation 6.2, we m ore ap propriately analyze average utility per second. T he following explanation should clarify this distinction. As th e cost increases, th e arrival rate goes down, w aiting goes down, and th e expected benefit goes up (because we filter out call requests w here b < c). W hen th e cost is very high the expected benefit is also very high but th e arrival rate is very low so not m any individuals use th e network. We need to avoid looking at cases where relatively few users w ith large benefits are th e only users who gain access to the network, i.e. a few users per year. W hen consider ing u tility per second, we consider the arrival ra te and don’t experience a spike in average u tility when only a handful of users access th e network. pU(p) = p (b — c) • / \ ------- 1 — wwait(/?) (6.3)j E quation 6.3 defines average u tility per second. We now derive an analyticall solution to show when charging will increase utility. Let A0 and pa equal th e arrivalj rate and traffic intensity in th e free netw ork, and let Ac and pc equal the filtered arrival rate and traffic intensity in th e netw ork w ith cost c. Charging will increase j u tility whenever th e average u tility per second in th e cost netw ork, pcU (pc), exceeds th e average utility per second in the free network, p0U (po)- For the naive m odel we set Po = ~ ^ and Pc = For c > 0 we arrive at th e following derivation: PcU (pc) > poU (po) (6.4) ( b - c ) P to wait (pc) > Po P — uiwait (p0) (6.5) P c— — — > p o — — /?Q «?wait (p0) + pcwwait (pc) P P P c— ~ P c— > P o - ~ po^w ait (p0) + /3cu;wait (pc) P P P p c — < P c— — P o ~ + p 0w w ait (p 0) - pcuiwait (p c) P P P c b b Pc * ' ' ■ Pc po + p p p (6.6) (6.7) (6 .8) (6.9) w p o (np0)n n\ (1 - po) wpc (npcT n\ (1 - pc) c < 4 - ^ + Pc w nnp*+ 1 i + (np°}n + ^ (np°Y n ! (1 - />.) 2 = 1 1 1 -1 n p ( 1 - p0) i + (n ^ ) ” + ^ 2 (npcy n ! (1 - Pc) t=i - i np( 1 - pc) (6.10) pcnl (1 - p0) w nnPc+ 1 i + (n^ )n + (np°y n\ (1 - p0) j=i - l n I + (n^)n } ^4 (npcT pcn\ (1 - pc) [ n\ (1 - pc) i= 1 ll n (1 po) 1 ( ! — Pc) i bpo w n n V o +1 c < b ---------- h Pc pcn \ ( l - p oy 1 + (npo)n + ^ 4 (npoy n! (1 - p0) i= i - i w nn 1 p ™ n • (1 - PcY i + (np^ n + ^ 2 (np° n\ (1 - pc) 2 = 1 l\ (6 .11) 73 As we discuss above, the predictive m odel allows users th e opportunity to w ith hold th eir requests if th e expected delay is unacceptable. T he effect is to reduce the arrivals in th e free netw ork so th a t all users who chose to request netw ork service find the actual delay acceptable. We determ ine the arrival rate such th a t the ex pected delay equals th e actual delay. T he calculations for the predictive m odel are perform ed as follows. Let p equal th e arrival rate such th a t th e expected waiting equals th e actual waiting. We know th a t w ait(p) equals th e actual delay. In the predictive m odel users will place a call whenever: U(p) > 0 (6.12) —— — — inwait(/>) > 0 (6.13) otherw ise they receive zero u tility because in placing the call, th eir u tility would be negative. Their utility could be less th an zero for one or m ore of th e following reasons: th eir benefit was too low, th e cost was too high, th e constant on the w aiting term , w, was too large, or th e actual w aiting was too long. Isolating b in E quation 6.13 yields: b > pwwait(p) -f c (6-14) We now know precisely how to filter th e arrivals in th e free network. T he arrivals in th e free netw ork, A 0, should be reduced by the population of users whose benefit falls below pwwait(p)-\-c. For the predictive m odel we perform the following substitutions in E quation 6.11 above: (C-M fl f M ix) po = ---- ------------------------- p n ^O ( / ^ w a i t ( p ) + c / ( z ) dx) Pc = —i (6.15) pn w here f(x) is th e p.d.f. for an arb itrary benefit distribution for b. 74' ___t E quation 6.11 gives th e precise solution w hen charging increases utility for an M /M /n queue; however, outside of testing specific values it is analytically in tractable. In Section 6.2.1.1, we will analyze various values for pQ , b, and c. We provide th e derivation for th e sim pler M /M /1 queue below: pcU (pc) > p0U (po) (b -c ) P icw ait (pc) > po icw ait (po) P (6.16) (6.17) (b -c ) Pc > b P o - - PoW p b c Pc pc > p b P o - - p0w p p C p b b P c ~ < P c - - P o - P p p C b b P c ~ < P c - - P o - P p p C < b - ,) (6.18) p0w w ait (p0) + pcw w ait (pc) (6.19) wait (pc) (6.20) (6.21) (6.22) 2 1 9 1 W P o £ W P c r 1 - Po 1 - Pc Wp2 0 Wpc pc ( l - p o ) 1 ~ pc where c > 0, w is an arb itrary constant on the w aiting term , and Po — and pc = A o / X A ° ( - C w a i t ( p ) / < * ) * * * ) , _ X° ( f Z ^ i t ( p ) + c t t XU X) ^ for the naive m odel while pQ = — p L an(j p for th e predictive m odel. In Section 6.2.1.1, we will analyze Equation 6.22 in light of both th e naive and predictive models for two specific benefit distributions: Uni- form [0,l] and an E xponential w ith a m ean of 1. Before we end our queueing m odel discussion we would like to briefly introduce a recent m odel proposed by A rnott et al. [2] who analyzed th e effect of tolls on freeway system s. T heir m odel used an M /D /n queue whose queueing property differs from our M /M /n m odel in th a t th e form er m odel can increase utilization w ithout increasing delay. They were able to show th a t when users were allowed to * 751 d istrib u te th eir departures in tim e, coupled w ith a peak load pricing scheme, th a t charging can increase utility before redistribution. They showed th a t th e freeway can reach 100% utilization and th a t traffic delays went to zero. This result can be directly applied to com puter com m unications networks provided th a t user requests can be characterized by a M /D /n queue and th a t peak load pricing is used. 6 .2 .1 .1 E v a lu a tio n and A n a ly sis o f Q u eu ein g M o d e ls This section evaluates the effectiveness of the queueing models. T he objective is to articu late precisely when charging increases utility. In this m odel, pricing is designed to decrease waiting. W aiting is essentially w asted utility, i.e. a deadweight loss. N either the service provider nor service user benefits through waiting. The established price should be high enough to discourage a fraction of th e users w ith lower benefits from using th e network b u t low enough to encourage the m ajority of users to subm it service requests. An analogy can be draw n from th e incorporation of tolls on m ajor throughways[2]. A m ain com ponent of th e fare is designed to decrease w aiting and not to raise revenue. We have described two reservation oriented netw ork models: naive and predic tive. In both netw ork m odels, cost is known a priori and service is guaranteed once granted by the adm ission control policy. In th e naive m odel th e w ait rem ains the only nondeterm inistic param eter affecting utility; however, in th e predictive m odel we provide users w ith the precise delay so th a t they can w ithhold th eir service re quests in the event th a t th e actual delay exceeds an acceptable level. O ur objective is to analyze how price influences th e user’s utility in b o th m odels. O ur selection of naive and predictive models allows us to analyze both ends of th e spectrum w ith respect to knowledge of delay. In th e form er m odel users have no knowledge of delay while in the la tte r m odel users have com plete knowledge. Any other model is somewhere in between. Given Equation 6.22 for th e M /M /1 queue, we would like to show precisely when charging increases u tility for both th e naive m odel and predictive models. We will first address th e naive m odel and then present our analysis for th e predictive model.i W e begin our analysis by considering th e effect th a t th e w ait constant, w, has I on E quation 6.22. ! 1. W ith a w ait constant, w = 0 (a) The last two term s in th e utility equation are zero because th e constants on th e w aiting term s are zero. (b) The sum of th e first two term s is nonpositive because p0 > pc when c > 0 so y- > 1. So th e above equation simplifies to: c < b — Since the right hand side never exceeds 0, charging does not increase u tility when w = 0. This phenom enon occurs because the constant suppresses th e beneficial effects produced by charging. 2. W ith w > 0 (a) As in step lb above, the sum of the first two term s rem ains nonpositive. (b) T he sum of the la tte r two term s is nonnegative. Since p0 > pc when c > 0 we know th a t . It follows th a t — po < — rr^2 — > 0 — 1 —Po — 1 - P c Pc (1 — Po) 1 — Pc — since ^ > 1. Therefore, it is possible to apply a positive constant to the w aiting term s such th a t a charge will increase u tility whenever c > 0 and w ait(p0) > 0. Figures 6.1 — 6.3 plot u tility per second curves for several input arrival rates and choice of benefit. These exam ples were selected to dem onstrate the qualitative properties for increasingly sm aller average delays given in th e above analysis. Each figure plots u tility per second as a function of increasing cost for different wait sen sitivity param eters, w. As w increases, the effect th a t charging has on u tility also increases because th e naive m odel has no inherent feedback property. Charging in creases u tility w herever the curve has positive slope. T he figures also graph average queueing delay in seconds as a function of cost. We note th a t the average queueing delay is inversely proportional to cost.4 T he relationship betw een charging and utility is far m ore complex in the pre dictive m odel. In th e predictive m odel we need to filter out the portion of users whose benefit does not com pensate for the actual delay. We assum e th a t individual j 4In Figure 6.3 the average queueing delay is virtually fiat due to the low traffic intensity;! however, the average queueing delay still decreases w ith cost as evident by the concave utility per second curves with higher wait sensitivities. 77 j ___I util per sec util per sec 0.39/0.004/100 Queue with U[0,1] Expected Benefit 0.39/0.004/100 Queue with Fixed Benefit, b= 0.35 75 -i 75 avq de X a v • ( s e c ) avg delay ' ( s e c ) 60 - 60 - \ w= 0 . 2 5 45 - V w= 0 . 2 5 30 - 30 - 15 0 . 0 5 0 . 1 0 . 1 5 0 . 2 0 . 2 5 0 . 3 0 . 3 5 0 0 .0 5 0 . 1 0 . 1 5 0 . 2 0 .2 5 0 . 3 0 . 3 5 0 cost per second cost per second Figure 6.1: Naive Model U tility per Second w ith pa — 0.975. 0.525/0.0075/75 Queue with 0.525/0.0075/75 Queue with U [ 0,1] Expected Benefit Fixed Benefit, b= 0.5 35 avg \ d e l a v • ( s e c ) 30 - V; 25 - 20 - 15 - 10 - 0 .0 5 0 . 1 0 . 1 5 0 .2 0 . 2 5 0 . 3 0 . 3 5 0 35 n avg N d e la v *( s e c ) 30 - 25 - \ w = 15 - 10 - 0.3 0.35 0 .2 0.2 5 0 0.G5 0.1 0.15 cost per second cost per second Figure 6.2: Naive M odel U tility per Second w ith p 0 = 0.933. 0.325/0.01/50 Queue with U[0,1] Expected Benefit 0.325/0.01/50 Queue with Fixed Benefit, b= 0.6 17.5 15 ■ 12.5 - util per V d elay ( s e c ) 15 7 . 5 - 2 . 5 \ w * 1 w= 10 w= 100 V w= 1000 0 .0 5 0 . 1 0 . 1 5 0 .2 0 .2 5 0 .3 cost per second \ w= 10 w= 100 S avg V d elay * ( s e c ) - - p . — — — p . — — m m p . — — — - p — — 1 - - - - - - - - - - - - - - - - - - - , 0 . 0 5 0 . 1 0 . 1 5 0 . 2 0 .2 5 0.3 cost per second Figure 6.3: Naive Model U tility per Second w ith p0 = 0.650. users know their own benefit and th a t th e netw ork can provide the cost and actual delay. Given this inform ation th e user is able to determ ine w hether placing th e call would net a positive utility. Since we know th a t the resultant u tility will always be positive when a user makes a service request, we can calculate the m inim um value of b for which users will request service from the network. In a sim ilar m anner as we perform ed in Section 6.2 for the M /M /n queue, we calculate b as follows: ( b -c ) U(Pc) > 0 (6.23) w * actual jwaiting > 0 (6.24) b > p, * w * actual jwaiting + c (6.25) For a general benefit distribution w ith probability density function (p.d.f.) f (x) J I the value of p having this property becomes: I A(t ( j. * w * a ct ua I _w a i t ing+c f(x)dx ) (6.26) 79 w here c = 0 in the free netw ork and e > 0 in th e cost network. We know th a t actual-waiting = from th e M /M /1 queueing form ula so th e equation for p can be rew ritten as: * ( f ° ° /(ar)rf®'] p = V -----------------------L (6.27) fl X r°° 9 = f ^ dx (6’28) P '/ rr?+c We can now calculate th e precise value for p w here th e expected delay equals the actual delay. We analyze two benefit distributions: Uniform [0,l] and Exponential w ith a m ean of 1. Each benefit distribution characterizes a distinct im plicit elastic dem and function used to filter th e input arrivals in th e free network. A U niform [0,l] distribution has a p.d.f. f ( x ) = ^ 3 5 = Pr e c i se value for p using this benefit distribution can be calculated as follows: p = — ( [ dx J (6.29) P V t^ + ‘ X —x p l— p 1 (6.30) p = A ( i _ _ ^ f L _ _ c) (0.31) p. i p A Awp Ac . P = ----------------- ----------- 6.32 p p(l - p ) p 0 A A p A wp Ac Xcp p 2 = ------- - ------------------+ — (6.33) p p p p p 9 A A p Xwp Ac Xcp , 0 = p2 - p + - - - t JL - — + —L ( 6 .3 4 ) i I A i \w A c i /fX I ^ I Ac\2 dA j ^Ac _ ^ M M ^ M M M ^_________ M ^ g g g -j 2 w here 0 < c < 1 , 0 < ^ < 1 , and w > 0. We supply a proof showing th a t p only has a single solution. Exam ine th e LHS and RHS of E quation 6.31. Given th e above restrictions on the input variables along w ith th e requirem ent th a t p > 0 (because a negative arrival ra te would not m ake sense), we note th a t the LHS is m onotonically increasing w ith p and th a t th e RHS is m onotonically decreasing w ith p\ therefore, there can be at m ost one crossing point in th e solution. If we know th a t th ere can be at m ost one crossing point, th en both solutions in th e quadratic equation cannot be valid. From Equation 6.36 we know th a t 1 + A q. A w _ A c ^ * ■ (J , H f£ * /(l + - + — — — )2 — 4 - + 4 — because 0 < c < 1; therefore, both solutions are V ' M M M ^ M ^ — positive. However, a valid solution would have 0 < p < 1, because if p = 1, th en E quation 6.31 would be undefined (we also know th a t the queueing form ula is undefined for p = 1). We can also show th a t th e solution for p does not pass through zero because substituting this value into E quation 6.33 yields 0 = A which is not tru e unless th e input arrival rate is zero. We conclude th a t the negative square root solution is th e only possible solution because if this value is not betw een zero and one, then th e positive square root solution cannot possibly be betw een zero and one. Therefore, th e sole solution for p in th e predictive m odel for a Uniform[0,l] distribution can be w ritten as: i I A _ I \w X c /f l I ^ I ^w 1^ I 1 M A 6 V - M M M A _____H A t ^g 2 We can now incorporate p into Equation 6.22 and derive when charging increases u tility for th e M /M /1 predictive m odel as a function of c, b, tt>, A, and p. We set pc equal to th e value calculated in Equation 6.37 and perform th e sam e substitution w ith c = 0 for p0 where the predictive constraint given in E quation 6.25 is still satisfied. T he equation becomes: 81 i _ _ _ _ _ i + ^ + - y / ( l + A + Af - M ) 2 _ 4 A + 4 ^ ( j _ A _ ^ + X/ ( 1 + A + Af ) 2 _ 4 i ) ^ ( l + ^ + ^ f - f - J ( l + i + ^ - ^ ) 2 - 4 A + 4 f ) —i v , - , . -L (6.39) l _ i _ i S " + A £ 4 . , / f l + i + i ” - i £ \ 2 _ 4 i + 4 k n M M Y M M * * M Since it is difficult to conclusively determ ine w hether the LHS of Equation 6.39 exceeds zero given th e above constraints, we num erically evaluate this equation while gradually increasing c and system atically substituting values for 6, to, and, - . W hen attem p tin g to find a price for which charging increases utility, we set th e benefit equal to the sm allest value such th a t th e resultant u tility per second is positive. Users having negative utilities indicate th a t their benefits are not high enough to request network service. It is precisely these users th a t the predictive m odel filters out. Hence, we exclude these users from our analysis. T he smallest acceptable benefit is calculated in Equation 6.25. As actual (not ju st potential) users’ sensitivity to w aiting increases, so does their benefit because we require b > actual .waiting + c to insure a positive utility. T he effect of a very large sensitivity to w aiting is th a t fewer individuals use the| netw ork because m ore users are forced out. If b increases, th en cost, c, increases! i for actual users. T he price required to increase utility rises w ith w because the increased sensitivity to waiting provides m ore of an opportunity to charge higher prices. We refer to Equation 6.22 for an explanation of these phenom ena. T he first two term s are prim arily benefit dependent while th e la tte r two w aiting term s are cost dependent. As we noted above, th e sum of the benefit term s is always negative while th e sum of the cost term s is always positive. W ith a higher benefit, th e charge required to increase utility m ust be higher because a greater negative effect m ust be overcome by the positive cost term s. At higher costs, th e difference in w aiting increases in com parison to th e free netw ork.5 Since we require a positive utility, we know th a t b > c because in th e predictive model we have b > p*w *actua!jw aiting + c > 0 and p * w * actual ^waiting > 0. Therefore, if c = 1, th en no one uses the netw ork because b ^ c,V b € UniformfO, 1], so pc = 0 and E quation 6.22 becomes undefined. In E quation 6.22, we showed th a t in the naive m odel when w = 0, charging never increases utility because c b — ^ for any c > 0. This result applies to the predictive m odel as well because if users are com pletely insensitive to w aiting then th e cost is always a liability. For w > 0, we need to evaluate a range of values for b and c given the benefit verses cost discussion above. One difficulty we had in testing increasingly smaller prices (i.e. c < le-15) is th a t th e solution for p no longer becomes distinct due to th e round off error. We had sim ilar problem s when testing large values for w (i.e. w > 10,000). We tested thousands of input param eters given these lim itations and could not identify one case in which charging increases utility for the predictive m odel w ithout redistributing the revenue. Tables 6.1 —6.4 contain the analysis of several such runs. We define pj as the input traffic intensity to th e predictive analysis, b as th e input benefit value, and w as th e w ait sensitivity param eter. Each table contains th e following data: cost per second (c/sec), predictive traffic intensity w ith cost c (pc), u tility per second (U/sec), revenue per second (R/sec), and absolute utility per second calculated as th e sum of u tility and revenue per second (Abs U/sec). Given these lim itations, we conclude th a t it is not possible to establish a price such th a t charging increases u tility in th e predictive m odel w ithout 5A similar argument can be used to show that if w decreases, then b decreases and c decreases. [ i i i ! i 83 revenue redistribution.6 We hope to establish an analytical, as oppose to num erical, result in future work. This result is not a general property of M /M /n or M /M /1 queueing models; rath er, it is a property of th e m anner in which we constrain th e problem space in u tility after redistribution; see the last colum n in each table titled Abs U/sec. free netw ork and started charging at this fixed point, then it is possible to increase utility prior to redistribution. However, in our predictive m odel, we allow users the ability to self consistently recom pute the delay for each cost. Therefore, users are aware of th e effect th a t each cost has on the average delay. It is in this specific, well inform ed, condition th a t charging fails to increase utility. O ur selection of naive and predictive models allows us to analyze b o th ends of the spectrum w ith respect to knowledge of delay. In th e form er m odel users have no knowledge of delay while in th e la tte r m odel users have com plete knowledge. Any other m odel is somewhere in between. We next perform th e M /M /n queueing analysis using an E xponential benefit d istribution for th e im plicit dem and function. We begin the predictive analysis by rew riting E quation 6.28 for a general benefit distribution below: 6We also numerically analyzed the M /M /n queue and found no qualitative difference in the; result. 1 th e predictive m odel. As shown in the tables, we found th a t it is possible to increase T he reason u tility does not increase prior to redistribution is a result of the users’ predictive property. If we sim ply allowed users th e ability to predict the delay in the P (6.40) T he p.d.f for an exponential benefit distribution is f ( x ) = Ae A a:. For a m ean of 1 the p.d.f. becomes f(x) = e~x. We can derive th e precise value for p as follows: P (6.41) C O P (6.42) P 841 ___I c/sec Pc U j sec R/sec Abs U/sec 0.000 0.713459 0.093470 0.000000 0.093470 0.075 0.678375 0.063821 0.050878 0.114699 0.150 0.639198 0.033775 0.095880 0.129655 0.225 0.596064 0.004432 0.134114 0.138547 0.300 0.549243 -0.022985 0.164773 0.141788 0.375 0.499094 -0.047233 0.187160 0.139927 0.450 0.446015 -0.067130 0.200707 0.133577 0.525 0.390408 -0.081613 0.204964 0.123352 0.600 0.332647 -0.089763 0.199588 0.109825 0.675 0.273064 -0.090811 0.184318 0.093507 0.750 0.211949 -0.084122 0.158962 0.074840 0.825 0.149545 -0.069177 0.123375 0.054198 0.900 0.086055 -0.045559 0.077450 0.031891 0.975 0.021648 -0.012928 0.021107 0.008178 Table 6.1: Predictive analysis w ith pj = 0.95,6 = 0.38, and c/sec Pc U /sec R/sec Abs U/sec 0.000 0.035 0.070 0.105 0.140 0.175 0.210 0.161484 0.156026 0.150553 0.145064 0.139561 0.134042 0.128508 0.030265 0.024984 0.019988 0.015278 0.010858 0.006730 0.002897 0.000000 0.005461 0.010539 0.015232 0.019538 0.023457 0.026987 0.030265 0.030445 0.030527 0.030510 0.030397 0.030188 0.029884 Table 6.2: Predictive analysis w ith pj = 0.2, 6 = 0.38, and c/sec Pc U/sec R/sec Abs U/sec 0.000 0.356602 0.123296 0.000000 0.123296 0.075 0.335709 0.107305 0.025178 0.132483 0.150 0.313933 0.091799 0.047090 0.138889 0.225 0.291251 0.076909 0.065531 0.142440 0.300 0.267640 0.062775 0.080292 0.143067 0.375 0.243082 0.049553 0.091156 0.140709 0.450 0.217559 0.037409 0.097901 0.135310 0.525 0.191056 0.026522 0.100304 0.126827 0.600 0.163563 0.017085 0.098138 0.115222 0.675 0.135070 0.009298 0.091172 0.100470 0.750 0.105573 0.003375 0.079180 0.082554 Table 6.3: Predictive analysis w ith p f = 0.8,6 = 0.9, and p = A e- f ^ + c (6.43) Since we could not determ ine th e general solution for p from Equation 6.43 as we did for the Uniform [0,l] distribution, we perform ed a num erical analysis to determ ine when charging increased utility. We found no qualitative difference from the con clusions draw n from the form er distribution. Namely, in th e naive m odel, we could always find a constant applied to the w aiting term such th a t charging increased u til ity and th a t redistribution was always required in th e single class predictive m odel to increase utility. 6.2.2 S im u latio n M od els Given the com plexity Equations 6.22 and 6.39 for the single QoS netw ork, a realistic m ultiple service class netw ork would have an extrem ely complex problem space th a t would be difficult to capture using an analytical model. We use sim ulation to study th e naive and predictive models in the context of a m ore complex m ultiple service class netw ork m odel. Im plem enting th e naive m odel is straight forward because their is no w ait prediction so th e input arrivals for the free netw ork are only filtered by the cost. Since we cannot calculate th e exact average delay in th e predictive sim ulation m odel, we estim ate it using th e current average delay for a given guaranteed QoS user class. For th e free network, the current average delay and cost will be used to filter th e input arrivals. We extend th e queueing models in three ways. F irst, we allow users to giveup in real-tim e if th e actual delay causes their utility to becom e negative. Usually, when users subm it service requests th a t are not im m ediately accepted by the network, they are forced to w ait until th e service is granted.7 W hen users giveup, we assum e they will resubm it the service requests at a later tim e. Allowing users to giveup le ts : them continue trying only for an acceptable period of tim e.8 We also analyze the 7Recall that in the predictive m odel the user knows the precise average delay; however, once the service request is subm itted, the user m ay still wait before obtaining network service. | 8In the sim ulation m odel, predictive users base their decision to use the network on the current j average delay for each service class. The current average delay will m ost likely be different fro m , | the actual delay as was used to filter the input arrivals in the queueing models. So, a predictive; user who subm its a service request but later gives up im plies that the user found the average , case w here users are not allowed to giveup once they subm it th eir service request to facilitate a m ore direct com parison to th e usual single class queueing models. Second, our sim ulation provides the flexibility to im plem ent an arb itrary adm is sion control policy. We could incorporate complex policies such as those proposed in [25, 30, 35]; however, we are not evaluating adm ission control per se. We choose to im plem ent a sim pler scheme based on th e effective bandw idth calculated by sum m ing th e bandw idth for all classes. T he th ird and final enhancem ent to th e queueing m odel is born out of the ex istence of a m ore complex service discipline and hence m ore com plex admission control policy. In our sim ulation m odel, we analyze three service classes com pared to ju st one in the queueing model. The first two services classes are reserved for distinct guaranteed QoS applications while th e last class carries background d ata gram traffic. Each guaranteed QoS class represents an application having different perform ance requirem ents such as throughput, delay, loss rate, etc. In fact, having three service classes w arrants a m ore complex adm ission control policy because each class has different netw ork and bandw idth requirem ents. Traffic generation for each user class occurs sim ilarly to th a t in th e queueing model. We also im plem ent an identical elastic dem and m odel th a t filters th e arrivals in th e free netw ork based on cost. We m aintain th a t the netw ork reserve no more th an x% of th e bandw idth for the guaranteed QoS classes [16]. T he rem aining (100 — x ) % quota ensures th a t datagram service will always be available. D atagram traffic in no way influences th e perform ance received by the guaranteed QoS classes and will be allowed to consume all residual bandw idth not reserved by th e first two classes [16, 35]. W hen designing th e queueing models, we were forced to consider average delays and hence average utility due to our analytical equations. Thus, we studied average u tility per second. In our sim ulation m odel we alter our analysis technique slightly and consider to tal utility because we can sum th e actual values obtained through sim ulation. We can im m ediately determ ine th a t to tal u tility is calculated from the acceptance of many users and not from a relatively small num ber of users who delay acceptable, however, the actual delay would have been too long so the service request was abandoned. I could accept extrem ely high costs. This m odification relieves us from calculating th e average and m ultiplying by th e arrival rate throughout all stages of the analysis. U tility for guaranteed QoS classes is calculated in a sim ilar m anner to E qua tion 6.2 except th a t we reflect actual rath er th a n average utility. We express actual u tility below: U Qos ( p c ) = rn(b — c) — wwa\t(pc) (6.44) where b equals th e benefit per second taken from a distribution, c equals the cost per second, m equals th e actual call duration, wait(pc) denotes th e actual w aiting calculated in the sim ulation w ith traffic intensity pc, and w is an arb itrary constant on th e w aiting term . Ju st as in the queueing m odel, the constant on the waiting term reflects th e user’s sensitivity to delay. E quation 6.44 calculates th e actual utility for a user in a guaranteed QoS class in th e event th a t th e user gains access to the network. If a user’s call request gets accepted on th e initial attem p t, then wait(pc) = 0, so th e user’s u tility becomes sim ply Uqos(Pc) = fn{b — c); however, if th e request is denied, th en th e user m ust wait. In th e case where we allow users to abandon their service request in real-tim e, we assum e th a t users will a ttem p t to gain access as long as they m aintain a surplus through placing th e call. T he following equation captures this relationship: m (6 — c) — u>curwait(/9c) > 0 (6.45) where curwait(pc) equals th e current wait experienced thus far. Upon each u n successful attem p t, the application resubm its th e request after a sm all random ly determ ined interval until Equation 6.45 is false. W hen E quation 6.45 fails, th e user receives a u tility of: Ugiveup{pc) = — u;curwait(/>c) (6.46) Since users do not place th e call, they neither receive a benefit nor incur a cost. In the case where users are not allowed to giveup, utility is always calculated as in E quation 6.44 once netw ork access is granted. 88 j ___! We now tu rn to im plem enting d atagram traffic. T he objective is to approxim ate transfer tim es for datagram applications such as file transfers (F T P ) and electronic m ail (Em ail) applications as if we were conducting a packet level sim ulation. This task is readily achievable since we are conducting discrete event sim ulation. Between adm ission control events and th e initiation and com pletion of datagram events, the link utilization rem ains constant so the residual bandw idth plus the am ount reserved for datagram application can be calculated and allocated to all datagram applications. The bandw idth received by any one datagram application is simply th e available bandw idth divided by the num ber of datagram applications. Of course, th e actual value could be weighted to favor a particular application, for exam ple to give an F T P application m ore bandw idth th an an Em ail application as if a priority or weighted fair queueing scheme were used [17, 19, 51]. D atagram user requests are initiated and filtered by cost ju st like guaranteed QoS user requests. There are no QoS guarantees or adm ission control for datagram users; therefore, th e netw ork accepts all datagram resource requests and drops excess packets. W hen a datagram user w ants to transfer a file or send an Em ail message, we first determ ine the file size according to a random exponential distribution. The datagram user’s u tility is a function of a random benefit, cost, and datagram perform ance m easure. We use norm alized throughput as th e d atagram perform ance m easure. Once we calculate th e actual throughput, we divide it by th e link speed to determ ine th e norm alized throughput. This m easure is useful because it is file size independent and accurately reflects a datagram user’s share of netw ork resources. This perform ance m etric roughly m easures th e datagram application’s packet level perform ance. T he datagram user’s sense of delay is realized through th e length of tim e required to transfer th e file rath er th an the length of tim e prior to the netw ork’s acceptance of th e service request. We assum e th a t delay sensitive, as opposed to throughput sensitive, applications don’t use datagram service. T hroughput sensitive applications are basically transm ission delay sensitive whereas other applications are also queueing delay sensitive. T he utility function for a d atagram application can be w ritten as: U d a t a g r a m ( p c ) = (6 “ c ) m + tO Nth T U put(/9c) (6.47) 89 where N thruput(pc) equals th e norm alized throughput for a d atagram user w ith an arrival rate of pc, b is th e random benefit, c is th e cost per m egabit required to obtain the d atagram service, m is the file size in m egabits, and w is an arb itrary constant on th e perform ance term . As w ith guaranteed QoS users, datagram users only place a service request when b > c. However, datagram users do not experience any type of delay before th eir request is accepted by th e network. In th e event their benefit does not exceed their cost, they m erely neglect to subm it their current resource request because th e cost is too high. In this case, the benefit obtained from subm itting the service request was too low. 6.2.2.1 Sim ulation D etails In this subsection we discuss the results of our sim ulated three class com puter com m unications network and com pare the results to those found in our suite of single class queueing models. We analyze three traffic configurations outlined in Table 6.5. T he table contains th e following data: configuration num ber, application type, num ber of applications of each type, average generation frequency (sec), and average duration (sec) or average file size (K bits) in the case of F T P . T he table contains m ean values. A ctual values are taken from an exponential distribution w ith th e specified m eans. We conducted over 3000 sim ulations using these three traffic configurations. Each sim ulation ran for 80,0000 sim ulated seconds including and initial warm up period of 10,000 seconds. We established fixed m inim um bandw idth requirem ents for our guaranteed service applications. Each Video application required 1 Mb of bandw idth in order to m eet its guaranteed service requirem ents while each voice application required 64 Kb in order to m eet its guaranteed service requirem ents. For each configuration we tested three link speeds used by th e adm ission control policy for accepting client requests as detailed in Table 6.6. In each configuration we set aside 10% for datagram applications. 6.2.2.2 E valuation and A nalysis of Sim ulation M od els O ur queueing m odel analyzed th e naive and predictive models for a single guar anteed QoS class network. In addition to adding m ultiple service classes in our i 1 90' c/sec Pc U j sec R j sec Abs U/ sec 0.000 0.083920 0.006959 0.000000 0.006959 0.075 0.078079 0.006018 0.005856 0.011874 0.150 0.072169 0.005136 0.010825 0.015962 0.225 0.066189 0.004315 0.014893 0.019207 0.300 0.060138 0.003556 0.018041 0.021598 0.375 0.054014 0.002864 0.020255 0.023119 0.450 0.047817 0.002239 0.021518 0.023756 0.525 0.041545 0.001684 0.021811 0.023495 0.600 0.035196 0.001204 0.021118 0.022321 0.675 0.028771 0.000799 0.019420 0.020219 0.750 0.022266 0.000474 0.016700 0.017173 0.825 0.015682 0.000230 0.012938 0.013168 0.900 0.009016 0.000072 0.008115 0.008187 0.975 0.002268 0.000003 0.002211 0.002214 Table 6.4: Predictive analysis w ith p j = 1, b = 0.999, and w = 10. Video Voice FT P Config num gen dura num gen dura num gen file uration apps freq tion apps freq tion apps freq size 1 70 700s 400s 350 491s 120s 100 50s 400Kb 2 100 700s 400s 250 491s 120s — — — 3 150 700s 400s 100 491s 120s 100 45s 500Kb Table 6.5: T hree Class Sim ulation Traffic Configurations. Config uration Link Speed 1 40 Mbps 45 Mbps 55 Mbps 2 50 Mbps 55 Mbps 65 Mbps 3 80 Mbps 85 Mbps 100 Mbps Table 6.6: T hree Class Sim ulation Link Speeds. 91 sim ulations, we incorporated a real-tim e option allowing users th e opportunity to abandon th eir service request in th e event th a t the actual delay is too long. Al lowing th e giveup option creates a to tal of four possible sim ulation m odels for each configuration and link speed: Naive w ith giveup, Naive w ith nogiveup, Predictive w ith giveup, and Predictive w ith nogiveup. In th e queueing m odel analysis, we em phasized the im portance of th e w ait sensi tiv ity param eter, w. In order to capture this im portance in our three class sim ulation m odels, we analyze four wait sensitivities for each traffic configuration, link speed, and sim ulation m odel discussed above. T he following wait sensitivities are used: 0.5, 1, 5, and 10. T he resulting values allow us to gain insight into how th e conclu sions from our enhanced sim ulation environm ent relate to th e conclusions reached from our queueing analysis. Two qualitative results are consistent w ith our queueing analysis. F irst, through out all of our sim ulation results, absolute u tility 9 first increases w ith price then de creases. This indicates th a t after redistribution, charging increases u tility.10 Second, th e naive m odel w ithout giveup can always increase to tal u tility before redistribu tion, by applying some constant to the w aiting term s. This result does not hold w ith the giveup condition because as the w ait sensitivity increases, th e delays decrease due to th e inherent property of th e feedback condition in th e giveup m odel. T h at is, when users are m ore sensitive to w aiting, they giveup m ore quickly, causing the arrival rate to decrease, which reduces th e delay. In th e single class queueing analysis, we m ade th e claim th a t under th e predictive m odel, charging never increased to tal utility (once again before redistribution). This claim does not hold in a m ulticlass m odel w ith diverse netw ork requirem ents. In a free netw ork, voice users have a m uch sm aller delay com pared to video users. This phenom enon is due to the n atu re of each application’s service request. Voice users have sm aller service requests, 64 K bps, while video users have m uch larger service requests, 1 M bps. Given an arb itrarily large network and an am ple num ber of voice and video users (relative to supply), voice users would happily fill up the entire network. Because th e network is large, high utilization can be achieved w ith 9We define absolute utility as the sum of total utility and total revenue generated from the ; individual application classes. i 10We adhere to the same redistribution philosophy outlined in the queueing analysis above. ! 92 I ______________________________________________________________________________________________I low delays. Upon, com pleting a voice call, a small am ount of bandw idth opens up leaving room for another voice call. Video calls require m any voice users to become sim ultaneously inactive in order to free enough bandw idth to support th eir requests. O ur sim ulations dem onstrate th a t small users can force out large users. W ith th e addition of charging, the queueing delay for video is drastically reduced because by turning away a fraction of voice and video users, larger holes are opened up for video calls. Voice delay is not drastically reduced because th eir delays are already low. In fact for small costs, voice delay at tim es increases due to th e lower delay experienced by video users, which pushes out a higher percentage of voice calls. W hen we consider utility, for th e m ost p art, video utility initially increases w ith cost while voice u tility always decreases w ith cost before redistribution. Once again after redistribution, charging initially increases utility for all applications. So charging alone does not increase utility for voice users because they already had a m echanism for squeezing out other users. T he predictive m ulticlass environm ent provides an opportunity to increase utility w here the single class network does not. D atagram users always show an increase in to tal u tility as a result of charging. Perform ance received by datagram users is solely a function of other users in the network. W hen the aggregate arrival rate falls off, datagram users are th e prim ary beneficiaries because they consume all residual bandw idth plus th e am ount specif ically set aside for datagram applications. For the highest costs, they frequently utilize the entire link because not m any other users (both d atagram and guaran teed) are active sim ultaneously, so their actual usage of th e netw ork is extrem ely short yielding a high percentage of th e bandw idth. T he effect is so pronounced th a t when a sufficiently large num ber of datagram applications are present (about 30% of th e to tal num ber of users) to tal u tility always increases.1 1 We are not able to display all of our sim ulation results. We have selected a repre sentative sam ple from th e first two configurations. Table 6.7 provides an overview of the sim ulation d ata presented in Tables 6.8 — 6.39. The tables contain the following data: cost per second, application queueing delay in seconds, datagram perform ance, “ Due to this result, we reanalyzed all runs excluding datagram applications to verify that the above multiclass delay analysis held for all traffic configuration, link speeds, and wait sensitivities. Reanalysis is possible because the presence of datagram traffic in no way influences the performance , of guaranteed service applications. application utility, to tal u tility sum m ed from the application classes, to tal revenue generated by all application classes, and absolute utility calculated by sum m ing to tal utility and revenue. T he first 16 tables display th e sim ulation results for all wait sensitivities on Configuration 1 w ith a link speed of 40 M bps. The second 16 tables display th e sim ulation results for all wait sensitivities on Configuration 2 w ith a link speed of 55 M bps. T he first group of tables include a datagram application while th e second group does not. Each group contains results from our four reservation oriented m ultiple service class models: naive w ith giveup, predictive w ith giveup, naive w ith nogiveup, and predictive w ith nogiveup. Each m odel contains results for th e following wait sensitivities: 0.5, 1, 5, and 10. We discuss Table 6.8 as an exam ple. We notice th a t as cost increases, voice delay decreases slowly; however, video delay rapidly decreases as explained in the above analysis. As a result, for increasing cost, voice u tility decreases because th e reduced delay is not large enough to com pensate for the reduced arrival rate. However, if we consider video, we notice th a t its u tility increases as a result of the rapid reduction in delay. Considering F T P ’s perform ance, we notice th a t it steadily increases w ith cost. This m ovem ent occurs because as th e cost increases, fewer F T P and guaranteed QoS users access the network; therefore, th e F T P users who gain access experience a greater share of the bandw idth since they consume all unused capacity. The above observations are consistent for over 95% of th e sim ulations we conducted. In th e eighth colum n, we find th a t for wait sensitivity, w = 0.5, to tal utility de creases as cost increases. We explain th e significance of th e w ait sensitivity param eter in the context of all four network models. For all naive models w ith nogiveup, to tal u tility is prim arily influenced by w (for Configuration 1, see Tables 6.10, 6.14, 6.18, and 6.22). Therefore, to ta l u tility can always be m ade to increase w ith cost for some w prior to redistribution. For naive models w ith giveup and all predictive m odels, larger w ait sensitivities decrease delays m ore rapidly due to th e feedback property as discussed above. Delays in th e free netw ork are lower because users either giveup m ore quickly (in both predictive and naive models w ith giveup) or find the delays unacceptable and never subm it the service request (in predictive m odels). In this case as discussed above, it is not always possible to increase to tal utility by increasing w. T he ninth column displays to tal revenue. As expected this value first increases w ith cost th en decreases. At lower costs, to tal revenue increases because users face increasingly higher costs but the cost is not high enough such th a t m ost users chose not to m ake service requests. However, as th e cost continues to increase, fewer and fewer users m ake service requests because th e high cost forces m ost users off th e network causing to tal revenue to decrease. T he final column contains absolute utility, the sum of to tal utility and to tal revenue. T his column represents u tility after redistribution. As m entioned above, absolute u tility always increases w ith cost initially, then decreases. T he explanation for this phenom enon is sim ilar to th a t of to ta l revenue. 95 Table number Sim ulation Model and Configuration Parameters 6.8 Conf 1 40 Mbps Link w = 0.5, Naive Model with giveup 6.9 Conf 1 40 Mbps Link w = 0.5 Predictive M odel w ith giveup 6.10 Conf 1 40 Mbps Link w = 0.5 Naive Model with nogiveup 6.11 Conf 1 40 Mbps Link w = 0.5 Predictive Model w ith nogiveup 6.12 Conf 1 40 Mbps Link w = 1, Naive Model with giveup 6.13 Conf 1 40 Mbps Link w = 1 > Predictive Model w ith giveup 6.14 Conf 1 40 Mbps Link w = 1, Naive Model w ith nogiveup 6.15 Conf 1 40 Mbps Link w = 1, Predictive Model with nogiveup 6.16 Conf 1 40 Mbps Link w = 5, Naive Model w ith giveup 6.17 Conf 1 40 Mbps Link w = 5, Predictive M odel with giveup 6.18 Conf 1 40 Mbps Link w = 5, Naive Model w ith nogiveup 6.19 Conf 1 40 Mbps Link w = 5, Predictive Model w ith nogiveup 6.20 Conf 1 40 Mbps Link w = 10, Naive Model with giveup 6.21 Conf 1 40 Mbps Link w = 10, Predictive M odel w ith giveup 6.22 Conf 1 40 Mbps Link w = 10, Naive Model with nogiveup 6.23 Conf 1 40 Mbps Link w = 10, Predictive Model w ith nogiveup 6.24 Conf 2 55 Mbps Link w = 0.5 Naive Model w ith giveup 6.25 Conf 2 55 Mbps Link w 0.5, Predictive Model w ith giveup 6.26 Conf 2 55 Mbps Link w = 0.5 Naive Model with nogiveup 6.27 Conf 2 55 Mbps Link w = 0.5 Predictive Model with nogiveup 6.28 Conf 2 55 Mbps Link w = T Naive Model with giveup 6.29 Conf 2 55 Mbps Link w = 1, Predictive Model w ith giveup 6.30 Conf 2 55 Mbps Link w = = 1, Naive Model w ith nogiveup 6.31 Conf 2 55 Mbps Link w = 1, Predictive Model w ith nogiveup 6.32 Conf 2 55 Mbps Link w 5, Naive Model w ith giveup 6.33 Conf 2 55 Mbps Link w 5, Predictive M odel w ith giveup 6.34 Conf 2 55 Mbps Link w = 5, Naive Model with nogiveup 6.35 Conf 2 55 Mbps Link w = 5, Predictive Model w ith nogiveup 6.36 Conf 2 55 Mbps Link w = 10, Naive Model w ith giveup 6.37 Conf 2 55 Mbps Link w = 10, Predictive Model with giveup 6.38 Conf 2 55 Mbps Link w = 10, Naive Model w ith nogiveup 6.39 Conf 2 55 Mbps Link w = 10, Predictive Model with nogiveup Table 6.7: Overview of Reservation O riented M ulticlass Sim ulation D ata. vcv vid ftp voice vid eo ftp to ta l to ta l a b so lu te co st dly d ly p erf u til u til u til u til revenu e u til 0 .0 0 1.92 106.21 9.52 2908358 8 35 6 9 6 692826 4 4 3 6 8 7 9 0 44 3 6 8 7 9 0.01 1.70 98.21 9.63 2881514 837105 696405 4 4 15025 8 0186 4495211 0 .03 1.73 8 7 ,3 0 9 .5 7 2 8 09803 840328 680 5 8 7 4 3 30718 198945 4 5 2 9 6 6 3 0.05 1.62 76.19 10.19 2 6 46947 872101 702871 4 2 2 1 9 1 9 390103 4 612022 0 .0 8 1.32 6 7 .8 5 10.36 2517879 857136 694343 4 0 6 9 3 5 7 573225 4 642582 0 .1 0 1.32 6 2 .8 7 10.40 2392850 840818 677212 3 9 10880 752594 4 6 63474 0.15 0 .9 8 42.66 11.44 2110281 829285 701020 3 6 4 0 5 8 7 1075074 4715661 0 .2 0 0 .7 4 25.50 12.84 1905228 792998 737526 3435752 1385930 4821682 0.25 0.44 15.51 17.72 1669022 722844 944006 3335872 1627274 49 6 3 1 4 6 0 .3 0 0 .2 3 6 .6 0 21.40 1466140 664990 1060902 3192032 1839086 5031118 0.35 0 .1 7 5.01 24.98 1258876 585867 1147202 2991945 2 016376 5008321 0 .4 0 0.06 1.42 31.74 1083366 498416 1340593 2922375 2 1 12010 5034385 0 .45 0.01 0.25 36.81 894 6 7 9 420440 1423922 2739041 2 174038 4 9 13079 0 .5 0 0 .0 0 0 .0 9 39.92 746770 364697 1403138 2514605 2239728 4754333 0.55 0 .0 0 0 .00 46.76 600 7 8 0 291016 1477606 2369402 2208372 4577774 0 .6 0 0 .0 0 0 .0 0 53.12 477555 219948 1490727 2188230 2 131563 4 3 19793 0.65 0 .0 0 0 .0 0 58.79 3 6 4 9 1 0 171034 1442048 1977992 2032781 4010773 0 .7 0 0 .0 0 0 .00 64.95 267361 124806 1359336 1751502 1 863438 3 6 14940 0 .8 0 0 .00 0 .0 0 7 7 .2 0 117855 54965 1 075214 1 2 48034 1397541 2645575 0 .9 0 0 .00 0.00 88 .7 9 28864 13617 621435 663917 773344 1437261 0 .9 9 0.00 0.00 98 .6 6 281 142 69658 70081 9 0 5 8 6 160667 Table 6.8: Conf 1, 40 M bps Link, w = 0.5, Naive M odel w ith giveup. vcv v id ftp voice video ftp to ta l to ta l a b so lu te co st dly d ly p erf u til u til u til u til revenu e u til 0.00 1 .4 7 8 3 .4 7 10.28 2918280 961 4 5 8 746171 4 6 2 5 9 0 9 0 4 6 2 5 9 0 9 0.01 1.59 86 .8 4 10.05 2900383 955741 725726 4581851 79998 4 6 61849 0.03 1.51 84 .3 4 10.54 2770152 934135 746736 4 4 51023 196338 4647361 0.05 1.43 76.32 10.67 2688857 886 1 5 9 734398 4309414 390801 4700215 0.08 1 .47 71.20 11.17 2524392 893 3 1 2 746538 41 64243 571931 47 3 6 1 7 4 0.10 1 .1 9 57.21 11.45 2422106 859 2 7 8 743031 4024415 752166 4776581 0.15 0 .8 9 40.32 12.73 2 1 42238 820272 777874 37 40384 10 79357 4819741 0 .20 0 .6 8 28.05 15.26 1913203 801419 873281 35 8 7 9 0 3 1369736 4 9 57639 0.25 0 .4 0 12.45 17.50 1667660 741202 932364 33 41225 1 623826 4965051 0 .3 0 0 .2 0 7.26 20.32 1480169 664858 1008176 3 1 53203 1850701 5003904 0.35 0.12 3.52 25.83 1250114 583057 1 185687 30 1 8 8 5 8 19 8 8 3 6 7 5007225 0 .4 0 0 .0 6 2.08 30.10 1089451 504094 1271946 2865491 2139306 5 0 04797 0.45 0.01 0.23 36.81 894 6 7 9 420 4 4 0 1 423947 2 739066 2 173977 4 9 13043 0 .5 0 0 .0 0 0 .1 6 39.94 7467 7 0 364696 1403771 2515237 22 3 9 4 6 8 4754705 0.55 0 .0 0 0.00 46.76 600 7 8 0 291016 1 477606 2369402 2208372 4577774 0 .6 0 0 .00 0.00 53.12 477555 219948 1 4 90727 2188230 2 1 31563 4 3 19793 0 .65 0 .0 0 0 .0 0 58.79 364 9 1 0 171034 1442048 1977992 2032781 4 0 1 0 7 7 3 0 .70 0 .0 0 0 .0 0 64.95 267361 124806 1359336 1751502 1863438 3 6 14940 0 .8 0 0 .0 0 0.00 77.20 117855 54965 1075214 1248034 1397541 2645575 0 .9 0 0 .00 0 .0 0 8 8 .7 9 28864 13617 621435 6639 1 7 773344 1437261 0 .9 9 0 .00 0 .0 0 98 .6 6 281 142 69658 70081 9 0 5 8 6 160667 Table 6.9: Conf 1, 40 M bps Link, w — 0.5, Predictive M odel w ith giveup. vcv v id ftp voice vid eo ftp to ta l to ta l a b so lu te co st dly dly p erf u til u til u til u til revenu e u til 0.00 2 .4 9 215.67 9.44 2911092 469013 687459 4 0 67564 0 4 0 67564 0.01 2 .4 9 199.30 9 .6 7 2 8 85517 500057 699356 4 0 8 4 9 2 9 81250 4 1 66179 0.03 2.51 191.65 9.46 27 66327 523652 672 6 1 7 3 9 6 2 5 9 7 199056 4161653 0.05 2.05 179.68 9.66 26 57617 539770 667645 3 8 65032 393706 4 2 58738 0.08 2 .2 9 176.49 9.94 2 4 98810 544439 666965 3 7 10214 577593 42 8 7 8 0 7 0 .1 0 1.99 136.78 9.81 2 3 80399 607165 639661 3 6 2 7 2 2 6 759453 4 386679 0.15 1.38 96 .0 7 11.07 21 30040 644898 6 7 8 6 1 7 3 4 5 3 5 5 5 1 0 87427 4540982 0.20 1.27 67 .2 8 12.78 1870196 655786 734035 3 2 6 0 0 1 7 1380042 4640059 0.25 0 .5 7 27.78 16.83 1666514 686599 897395 3 2 5 0 5 0 8 1628362 4 8 78870 0.30 0 .2 4 13.24 22.44 1473718 610679 1111956 3 1 96354 1 8 35137 5031491 0.35 0.31 10.56 23.01 1281336 582965 1057727 2922028 2 0 47728 4969756 0 .40 0 .0 4 1.65 29.49 1075362 504750 1246536 2826648 2131984 4958632 0 .45 0 .0 8 1.59 34.52 911310 429675 1 3 35940 2676925 2 2 33606 4910531 0.50 0.01 0 .13 41 .1 9 745846 357495 1 4 47413 2550755 2222131 4772886 0.55 0 .0 0 0 .00 47 .9 7 606944 281361 1515798 2404103 2191754 4 5 95857 0 .6 0 0.00 0.00 53.12 477555 219948 14 90727 2188230 2 1 31563 4319793 0.65 0 .0 0 0 .0 0 58.79 364 9 1 0 171034 1 4 42048 1977992 2032781 4010773 0 .7 0 0 .0 0 0 .00 64.95 267361 124806 1359336 1751502 1 8 63438 3614940 0 .8 0 0.00 0 .00 77.20 117855 54965 1075214 1248034 1397541 2645575 0 .9 0 0 .0 0 0 .00 8 8 .7 9 28864 13617 621435 6 6 3 9 1 7 773344 1437261 0 .9 9 0.00 0.00 98 .6 6 281 142 69658 70081 90586 160667 Table 6.10: Conf 1, 40 M bps Link, w = 0.5, Naive M odel w ith nogiveup. vcv vid ftp voice vid eo ftp to ta l to ta l a b so lu te co st d ly d ly p erf u til u til u til u til revenu e u til 0.00 2 .0 3 1 35.47 11.66 2907674 924698 842 9 7 9 4675351 0 4675351 0.01 1.78 1 24.20 11.99 2875552 917348 860662 4653561 79207 4732768 0 .03 1.38 87.11 12.15 2779525 942604 856 3 7 7 45 7 8 5 0 7 196304 4774811 0.05 1.18 86 .0 3 12.90 2 6 69267 910358 8 8 2 9 1 7 4462542 385805 4 8 48347 0 .0 8 1.51 97 .6 0 12.53 2509541 855777 834743 4200061 566971 4767032 0 .1 0 0 .6 7 60.15 15.38 2374865 839682 989946 4 2 0 4 4 9 3 731853 4 9 36346 0.15 0 .7 9 54.28 16 .1 0 2144196 819882 978 3 0 4 3942382 1059750 5002132 0 .2 0 0 .8 8 35.31 17.41 1910706 756595 993735 3 6 61036 1359222 5020258 0.25 0 .4 9 22.88 18.62 1671067 715146 991287 33 77500 1618049 4995549 0.30 0.21 10.98 24 .8 9 1461933 629116 1231617 33 22666 1803702 5126368 0.35 0 .1 3 4.96 26 .6 0 1291231 581916 1220838 3 0 93986 2019456 5113442 0 .4 0 0 .0 4 9 .53 31 .7 2 1074264 481330 1339985 28 95580 2107316 5002896 0.45 0 .0 5 9.91 35 .1 8 891792 420262 1361348 2673402 2197715 4 8 7 1 1 1 7 0 .5 0 0.01 0.12 41.22 745846 357495 1448444 25 51786 2221680 4 7 73466 0.55 0.00 0 .00 4 7 .9 7 606944 281361 1515798 2404103 2191754 4 5 9 5 8 5 7 0.60 0 .0 0 0.00 53.12 477555 219948 1 4 90727 21 88230 21 31563 43 1 9 7 9 3 0.65 0 .0 0 0.00 58.79 364910 171034 1442048 1977992 2032781 4 0 10773 0 .7 0 0.00 0 .00 64.95 267361 124806 1359336 1751502 1863438 3 614940 0.80 0.00 0 .00 77.20 117855 54965 1075214 1248034 1397541 2645575 0 .9 0 0 .0 0 0 .00 8 8 .7 9 28864 13617 621435 663 9 1 7 773344 1437261 0 .9 9 0 .0 0 0 .00 98 .6 6 281 142 69658 70081 9 0 5 8 6 160667 Table 6.11: Conf 1, 40 M bps Link, w = 0.5, Predictive M odel w ith nogiveup. co st vcv d ly v id dly ftp p erf voice u til vid eo u til ftp u til to ta l u til to ta l revenue a b so lu te u til 0 .0 0 1.40 64 .9 6 9 .5 4 2904623 7 73 0 4 7 1360854 5038524 0 5038524 0.01 1.19 59.92 9 .7 0 2873860 763712 1374563 5012135 8 0468 5092603 0 .0 3 1.16 51.49 9 .7 6 2784705 796824 1359910 49 41439 198671 5140110 0.05 1.22 46.20 10.20 2627207 783794 1381367 4 7 92367 388285 5180652 0 .0 8 1.05 40.71 10.48 2491532 795238 1379530 46 66299 570490 5236789 0 .1 0 0 .8 8 33 .2 2 11.19 2392527 795849 1430121 46 18497 751124 5369621 0.15 0.66 21.60 12.60 2147782 783560 1520111 4451453 10 8 2 4 0 7 5533860 0.20 0 .5 7 16.84 14.38 1869529 741190 1630053 4240772 13 62860 5603632 0.25 0.24 8 .96 17.21 1693234 715451 1819163 4 2 27848 1638226 5866074 0 .3 0 0 .1 6 4 .83 21.06 1476461 646945 2074683 4198089 1851921 6 0 50010 0.35 0 .0 7 1.81 25.75 1255172 578834 2352904 4 1 86910 1 9 98605 6 1 85515 0 .4 0 0 .0 3 0.51 30 .5 8 1 0 64107 513394 2574271 4 1 51773 2116121 6267894 0.45 0.00 0.10 35 .6 8 897894 429544 2752780 4 0 80217 2 1 88773 6 2 68990 0 .5 0 0 .0 0 0 .09 40.18 745052 361 7 4 7 2817211 39 24010 2 2 41989 61 6 5 9 9 9 0.55 0.00 0.00 48.73 608 3 8 8 273655 3073596 3955639 2 1 8 3 6 3 7 61 3 9 2 7 6 0 .6 0 0 .0 0 0.00 53.12 477555 219948 2976957 3 6 74460 2131563 5 8 06023 0.65 0 .0 0 0.00 58.79 3 6 4 9 1 0 171034 2880664 3 4 16609 2032781 5 4 49390 0 .7 0 0.00 0.00 64.95 267361 124806 2716149 3 1 08316 1863438 49 7 1 7 5 4 0 .8 0 0.00 0 .00 77.20 117855 54965 2149309 2322129 1397541 37 1 9 6 7 0 0 .9 0 0.00 0 .00 88 .7 9 28864 13617 1242589 1285070 773344 2 0 58414 0 .9 9 0.00 0 .00 98.66 281 142 139313 139735 9 0586 230321 Table 6.12: Conf 1, 40 M bps Link, w = 1, Naive M odel w ith giveup. vcv vid ftp voice vid eo ftp to ta l to ta l a b so lu te co st dly dly p erf u til u til u til u til revenu e u til 0.00 1.26 57.91 10.30 2894122 882832 1467417 5244370 0 5 2 44370 0.01 1.24 57.90 10.39 2881078 872 3 7 8 1470935 5224390 8 0024 5304414 0.03 1.22 48.02 10.76 2760291 893734 1495912 5149937 195022 5344959 0 .05 1 .00 43.01 11.63 2632034 872 3 7 3 1570837 5075245 384 4 4 6 5459691 0 .0 8 0 .8 6 34.85 12.48 2494738 881 1 9 4 1638052 5013984 563301 5577285 0.10 0 .8 3 34 .5 9 12.29 2380591 853012 1568564 4802168 7420 4 3 5544211 0.15 0 .6 8 24.63 13.46 2 1 40643 823425 1621303 4585372 10 71574 5656946 0 .20 0.35 12.77 15.91 1885648 782505 1800947 4 4 69100 1 3 54360 5823460 0 .25 0 .2 0 5.94 20.30 1681401 687536 2142959 4511896 1613631 6 1 2 5 5 2 7 0 .30 0.19 5.04 21.58 1446751 652141 2125963 4224854 1 8 20530 6 0 45384 0.35 0.05 1.93 26.50 1267281 568957 2420559 4 2 5 6 7 9 7 1996755 6253552 0 .4 0 0 .0 3 0.85 29.88 1086702 507297 2515119 41 09118 21 37079 6 2 4 6 1 9 7 0.45 0.01 0 .24 36.05 917 8 2 6 424965 2781267 41 2 4 0 5 8 2206445 63 3 0 5 0 3 0 .5 0 0 .0 0 0 .1 0 41.31 741127 360575 2895965 39 9 7 6 6 7 2 2 18229 6 2 15896 0.55 0.00 0.00 48 .7 3 608388 273655 3073596 3 9 55639 2 1 8 3 6 3 7 61 3 9 2 7 6 0.60 0 .0 0 0 .00 53.12 477555 219948 2976957 36 74460 2 1 31563 5 8 06023 0.65 0 .0 0 0 .00 58.79 364910 171034 2880664 34 16609 2032781 5 4 49390 0 .7 0 0 .0 0 0.00 64.95 267361 124806 2716149 3 1 08316 1 8 63438 49 7 1 7 5 4 0 .8 0 0 .0 0 0 .00 77.20 117855 54965 2149309 2322129 1397541 37 1 9 6 7 0 0 .9 0 0.00 0 .00 88 .7 9 28864 13617 1242589 1285070 773344 2058414 0 .9 9 0.00 0.00 98 .6 6 281 142 139313 139735 9 0 5 8 6 230321 Table 6.13: Conf 1, 40 M bps Link, w = 1, Predictive M odel w ith giveup. vcv vid ftp voice v id eo ftp to ta l to ta l a b so lu te cost dly dly p erf u til u til u til u til revenu e u til 0 .0 0 2.49 2 1 5 .6 7 9 .44 2849493 -112111 1347027 4084410 0 4 084410 0.01 2.49 1 9 9 .3 0 9 .6 7 2823993 -4 0 8 3 4 1371124 4 1 54283 8 1250 4 235533 0 .0 3 2.51 191.65 9 .4 6 2705707 5538 1318586 4029831 199056 42 2 8 8 8 7 0 .05 2.05 1 7 9.68 9 .66 2609182 60649 1309950 3979782 3 93 7 0 6 4 373488 0 .0 8 2.29 1 76.49 9 .94 2446375 80096 1309877 3 8 36348 577593 4413941 0 .1 0 1.99 1 36.78 9.81 2335914 243270 1256540 3835724 759453 4 5 9 5 1 7 7 0 .15 1.38 9 6 .0 7 11.07 2100743 387286 1336908 3 8 24937 1 0 87427 4 9 12364 0 .2 0 1.27 6 7 .2 8 12.78 1844920 477799 1450092 3772811 1380042 5 1 52853 0 .25 0 .57 27 .7 8 16.83 1655810 617099 1 7 79047 4051955 1628362 56 8 0 3 1 7 0.30 0 .24 13.24 22.44 1469490 579278 2210181 4258949 1835137 6 0 9 4 0 8 6 0.35 0.31 10 .5 6 23.01 1276217 558429 2103630 3938275 2047728 5 9 86003 0 .4 0 0 .04 1.65 29.49 1074758 501243 2483004 4059005 2131984 61 9 0 9 8 9 0 .45 0 .08 1.59 34.52 910214 426562 2663391 4 0 0 0 1 6 7 2233606 62 3 3 7 7 3 0 .5 0 0.01 0 .1 3 41 .1 9 745708 357271 2887802 3990781 2222131 6 2 12912 0 .55 0 .0 0 0 .0 0 47.97 606944 281361 3 0 25924 3 9 14229 2191754 6 1 0 5 9 8 3 0.60 0 .0 0 0 .0 0 53.12 477555 219948 2976957 3 6 74460 2131563 5 806023 0.65 0 .0 0 0 .0 0 58 .7 9 364910 171034 2880664 3 4 1 6 6 0 9 2032781 5 449390 0 .7 0 0 .0 0 0 .0 0 64.95 267361 124806 2716149 3 1 08316 1863438 49 7 1 7 5 4 0 .8 0 0 .0 0 0 .0 0 77.20 117855 54965 2149309 2322129 1397541 3 7 1 9 6 7 0 0 .9 0 0 .00 0 .0 0 88.79 28864 13617 1242589 1285070 773344 2 058414 0 .9 9 0 .0 0 0 .0 0 98.66 281 142 139313 139735 9 0586 230321 Table 6.14: Conf 1, 40 M bps Link, w = 1, Naive M odel w ith nogiveup. Table 6.15: Conf 1, 40 M bps Link, w = 1, Predictive M odel w ith nogiveup. vcv vid ftp voice vid eo ftp to ta l to ta l a b so lu te co st dly dly p erf u til u til u til u til revenue u til 0 .0 0 0 .8 7 100.32 18.88 2 9 59897 837082 2666698 6 4 6 3 6 7 7 0 6 4 6 3 6 7 7 0.01 1.14 76.12 17.13 2843200 927361 2408246 6 1 7 8 8 0 7 77374 6256181 0 .0 3 1.10 54.33 14.33 2774447 912142 1983878 5670468 194851 5 8 65319 0.05 0.90 63.02 18.06 2652419 917 2 5 3 2425139 5994811 378055 63 7 2 8 6 6 0 .08 1.23 61 .4 8 13.79 2 4 81067 884 4 7 9 1807663 5173208 562202 5 735410 0 .1 0 0.21 55.06 27.61 2422834 691221 3496582 6 6 10637 705489 73 1 6 1 2 6 0.15 0 .7 9 36 .7 3 17.98 2109273 795064 2159575 5063913 1047342 6 1 11255 0 .2 0 0 .4 6 34.73 20.27 1914561 706853 2 2 90014 4911428 ‘ 1342535 6 2 5 3 9 6 3 0.25 0.32 20.03 20.81 1665702 669 7 1 6 2 1 9 6 5 5 7 4531975 1598812 61 3 0 7 8 7 0 .3 0 0 .3 0 13 .6 8 24.26 1454758 612 5 8 9 2 3 88698 4456044 1803987 6260031 0 .35 0 .1 8 4.66 29.56 1259439 541352 2 6 98290 4499081 1971770 6470851 0 .40 0.06 2.95 30.95 1062887 494 7 5 9 2603368 4161014 21 01917 6262931 0.45 0.02 0.25 37 .1 9 904692 415955 2 8 69070 4 1 89717 2185343 63 7 5 0 6 0 0 .5 0 0.01 0.12 41.25 745708 357 2 7 0 2892061 3995038 22 21047 62 16085 0.55 0.00 0 .0 0 47.97 606944 281361 3 0 25924 3 9 14229 2 1 91754 6 105983 0 .60 0 .0 0 0 .0 0 53.12 477555 219 9 4 8 2 9 76957 3674460 2131563 5806023 0.65 0 .0 0 0 .0 0 58.79 364910 171034 2 8 80664 3416609 2032781 5 4 49390 0 .70 0 .0 0 0 .0 0 64.95 267361 124 8 0 6 2 7 16149 3108316 1 8 63438 4 971754 0 .80 0 .0 0 0 .0 0 77.20 117855 54965 2149309 2322129 1397541 37 1 9 6 7 0 0 .9 0 0 .0 0 0 .0 0 88 .7 9 28864 1 3 6 1 7 1242589 1285070 773344 2 0 58414 0.99 0 .0 0 0 .0 0 98 .6 6 281 142 139313 139735 9 0586 230321 I 100 co st vcv d ly v id dly ftp p erf voice u til vid eo u til ftp u til to ta l u til to ta l revenu e ab so lu te u til 0 .0 0 0.41 10.78 11.09 2 7 92410 706036 7774205 11272651 0 11272651 0.01 0 .3 4 10.04 10 ,9 7 2798445 728051 7647311 1117 3 8 0 7 79152 11252959 0.03 0.31 10.81 11.08 2707795 707859 7592074 1100 7 7 2 7 196384 11204111 0.05 0.28 8 .34 11 .8 8 2574961 731446 7919982 11226389 382820 11609 2 0 9 0 .0 8 0 .2 6 7.77 12 .2 3 2 4 6 7 8 4 7 711885 7935251 11114983 567 5 2 7 11682510 0.10 0 .1 7 5.24 13 .6 7 2341273 769577 8621324 11732174 737535 12469709 0.15 0.21 5.75 13.24 2093404 698808 7898708 10690920 1 0 68688 11759608 0 .2 0 0.10 2.81 16.08 1878316 716566 9030906 11625788 1 3 58943 12984731 0.25 0.07 1.61 19.35 1671074 679877 10151635 1 2 5 0 2 5 8 7 1614804 14117391 0.30 0.05 1.14 22 .4 7 1456903 629378 11012371 13098652 1833252 14931904 0.35 0.02 0 .28 26.74 1267514 553704 12164438 1398 5 6 5 6 1997652 15983308 0.40 0.00 0 .1 7 32 .5 5 1075191 479160 13655210 15209 5 6 0 2 102796 17312356 0.45 0.00 0 .0 4 36 .0 9 919 2 9 6 421094 13889208 1522 9 5 9 8 2215682 17445280 0 .5 0 0.00 0.00 42 .6 4 746693 350227 14917312 16014232 2202695 18216927 0.55 0.00 0.01 47.93 600 4 1 6 289263 15095159 15984838 2 1 88270 18173108 0.60 0.00 0.00 53.12 477555 219948 14866795 1556 4 2 9 9 2 1 31563 17695862 0.65 0 .0 0 0 .00 58 .7 9 364 9 1 0 171034 14389598 14925542 2032781 16958323 0.70 0 .0 0 0 .00 64.95 267361 124806 13570660 1396 2 8 2 7 1863438 15826265 0 .8 0 0 .0 0 0.00 77 .2 0 117855 54965 10742073 1091 4 8 9 3 1397541 12312434 0 .9 0 0 .0 0 0.00 88.79 28864 13617 6211820 6254301 773344 7027645 0 .9 9 0 .0 0 0.00 98 .6 6 281 142 696552 6 9 6 9 7 4 90586 787560 Table 6.16: Conf 1, 40 M bps Link, w = 5, Naive M odel w ith giveup. vcv vid ftp voice vid eo ftp to ta l to ta l a b so lu te co st d ly dly p erf u til u til u til u til revenu e u til 0 .0 0 0.35 10.39 11.76 2821491 815216 8246575 11883282 0 11883282 0.01 0 .3 0 10.24 12.57 2835522 822223 8761648 1241 9 3 9 3 78671 12498064 0.03 0 .2 8 8.14 12.82 2749835 861686 8780255 12391775 194624 12586399 0.05 0 .2 7 8.64 13.33 2 6 13959 823735 8882955 12320649 3 8 1 6 8 8 1270 2 3 3 7 0 .0 8 0 .2 3 6.94 14.01 2481785 781770 9088434 1235 1 9 9 0 559 8 2 0 12911810 0 .1 0 0 .1 8 6.28 15.28 2351807 784902 9634156 12770865 730987 13501852 0.15 0.15 5.56 15 .9 7 2107379 740660 9518101 12366140 1055223 13421363 0 .2 0 0 .1 0 2.84 18.03 1862183 719187 10121220 12702591 1 3 30968 14033559 0.25 0.05 1.64 20 .4 7 1669644 652766 10740393 13062803 1602364 14665167 0 .3 0 0.03 1.10 23.12 1467232 626833 11326610 13420675 1820989 15241664 0.35 0.02 0.45 28.23 1252811 555527 12842608 1465 0 9 4 6 1 9 71658 16622604 0 .4 0 0 .0 0 0.11 31.41 1075325 494240 13175950 14745515 2108594 16854109 0.45 0 .0 0 0.04 36 .1 4 919296 421091 13906722 1524 7 1 0 9 2215073 17462182 0 .5 0 0 .0 0 0.01 42.66 746693 350225 14924098 1602 1 0 1 6 2202425 18223441 0.55 0.00 0.01 47.95 600416 289263 15100210 1598 9 8 8 9 2188015 18177904 0 .6 0 0 .0 0 0 .00 53.12 477555 219948 14866795 1556 4 2 9 9 2131563 17695862 0.65 0 .0 0 0 .0 0 58.79 364910 171034 14389598 14925542 2032781 16958323 0.70 0 .0 0 0 .0 0 64.95 267361 124806 13570660 1 3 9 6 2 8 2 7 1863438 15826265 0.80 0 .0 0 0.00 77.20 117855 54965 10742073 10914893 1397541 12312434 0.90 0 .0 0 0.00 88 .7 9 28864 13617 6211820 6254301 773344 7027645 0 .9 9 0 .0 0 0 .00 98.66 281 142 696552 6 9 6 9 7 4 90586 787560 Table 6.17: Conf 1, 40 M bps Link, w = 5, Predictive M odel w ith giveup. co st v cv d ly vid dly ftp p erf voice u til v id eo u til ftp u til to ta l u til to ta l revenu e a b so lu te u til 0 .0 0 2.49 2 1 5.67 9.44 2356702 -4 7 6 1 1 0 3 6623574 4 2 19174 0 4219174 0.01 2 .49 199.30 9 .6 7 2331808 -4 3 67962 6745270 4 7 09116 8 1 2 5 0 4790366 0 .0 3 2.51 191.65 9 .46 2220748 -4139381 6486339 4 5 67706 199056 4766762 0 .05 2.05 179.68 9 .66 2221703 -3 7 7 2 3 1 2 6448395 4 8 97785 3 937 0 6 5291491 0 .0 8 2.29 176.49 9 .9 4 2026894 -3 6 3 4 6 4 4 6 4 53168 4 8 4 5 4 1 9 577593 5423012 0 .1 0 1.99 136.78 9.81 1980035 -2 6 6 7 8 8 9 6191569 5503715 759453 62 6 3 1 6 8 0 .15 1.38 96 .0 7 11.07 1866370 -1 6 7 3 6 1 7 6 603233 67 9 5 9 8 6 1 087427 7 8 83413 0 .2 0 1.27 67.28 12.78 1642712 -9 4 6 0 9 9 7 1 7 8 5 4 7 7875161 1380042 9 2 55203 0 .2 5 0 .5 7 27.78 16.83 1 5 70177 6 1098 8832261 10463535 1628362 1209 1 8 9 7 0 .3 0 0 .2 4 13.24 22.44 1435662 3280 6 7 10995978 12759706 1 835137 1459 4 8 4 3 0.35 0.31 10.56 23.01 1235263 3621 3 6 10470853 12068252 2 047728 14115980 0 .4 0 0 .04 1.65 29.49 1069928 4731 8 7 12374749 13917863 2 131984 1604 9 8 4 7 0 .4 5 0 .0 8 1.59 34.52 901 4 4 7 4016 5 4 1 3283005 14586106 2233606 16819712 0 .5 0 0.01 0.13 41 .1 9 744600 3554 8 0 14410912 15510992 2222131 17733123 0 .55 0 .0 0 0.00 4 7 .9 7 606944 281361 15106932 15995237 2 191754 18186991 0 .6 0 0 .0 0 0.00 53.12 477555 2199 4 8 14866795 15564299 2 131563 17695862 0.65 0 .0 0 0.00 58.79 364910 171034 14389598 14925542 2032781 16958323 0.70 0 .0 0 0.00 64.95 267361 124806 13570660 13962827 1863438 15826265 0 .8 0 0.00 0.00 77 .2 0 117855 54965 10742073 10914893 1397541 1231 2 4 3 4 0 .9 0 0 .0 0 0.00 8 8 .7 9 28864 13617 6 2 1 1 8 2 0 6254301 773344 7027645 0 .9 9 0.00 0.00 9 8 .6 6 281 142 696552 696974 90586 787560 Table 6.18: Conf 1, 40 M bps Link, w = 5, Naive M odel w ith nogiveup. co st vcv d ly v id dly ftp p erf voice u til vid eo u til ftp u til to ta l u til to ta l revenu e a b so lu te u til 0 .0 0 0 .2 6 29 .6 8 30 .3 3 2960123 690853 21222582 24873558 0 2487 3 5 5 8 0.01 0.74 26 .7 3 20.68 2825388 752508 14399490 17977384 75132 1805 2 5 1 6 0 .03 0 .3 8 20.20 23.07 2787533 709679 15780082 19277294 187991 19465285 0.05 0.21 26.52 32.03 2683148 661 9 2 7 21307968 24653044 356079 2500 9 1 2 3 0 .0 8 0.80 21.94 19.61 2442948 713904 1270 6 5 6 7 15863419 547347 1641 0 7 6 6 0 .1 0 0.38 18.07 22.14 2339505 667585 14004498 17011588 708281 1 7 7 1 9 8 6 9 0.15 0.35 12.51 24.60 2127339 672482 14657310 17457132 1019841 1847 6 9 7 3 0 .2 0 0 .5 7 10.40 23.32 1813447 651181 13088717 15553345 1286186 16839531 0.25 0 .2 0 12.02 26.19 1651170 533215 1373 7 4 9 7 15921882 1556726 17478608 0 .3 0 0 .3 7 5.63 30 .1 0 1412064 556524 14744606 16713194 1726761 18439955 0.35 0 .0 6 2.56 31.75 1273665 518463 14443675 16235803 1952741 18188544 0 .4 0 0.04 0.93 32.81 1090494 471073 13764301 15325868 2114118 17439986 0.45 0.01 0 .1 8 37 .2 6 910402 413681 14336142 15660225 2193230 17853455 0.50 0.01 0.12 41.45 744591 355432 14503848 15603870 2216814 17820684 0.55 0 .0 0 0.00 47 .9 7 606944 281361 15106932 15995237 2191754 18186991 0 .6 0 0 .0 0 0.00 53.12 477555 219948 14866795 15564299 2 1 31563 17695862 0.65 0 .0 0 0.00 58.79 364910 171034 14389598 14925542 2032781 16958323 0 .7 0 0 .0 0 0.00 64.95 267361 124806 13570660 1396 2 8 2 7 1 8 63438 15826265 0 .8 0 0 .0 0 0.00 77.20 117855 54965 10742073 10914893 1397541 1231 2 4 3 4 0 .9 0 0 .0 0 0.00 88.79 28864 13617 6 2 11820 6254301 773344 7027645 0 .9 9 0 .0 0 0 .0 0 98.66 281 142 696552 696974 90586 787 5 6 0 Table 6.19: Conf 1, 40 M bps Link, w = 5, Predictive M odel w ith nogiveup. vcv v id ftp voice vid eo ftp to ta l to ta l a b so lu te co st dly d ly p erf u til u til u til u til revenue u til 0 .0 0 0.16 4 .2 7 11 .7 7 2850421 711956 16485403 20047780 0 20047780 0.01 0 .1 7 4 .5 9 11.74 2768498 673 8 8 3 1 6336197 1 9778580 78758 19857338 0 .03 0.15 3 .64 12.31 2676067 703913 16848756 2022 8 7 3 6 193361 2 0422097 0.05 0 .15 3 .92 12.72 2572451 675 4 2 8 16934566 2 0182444 382785 2 0565229 0 .08 0.11 3.05 13.19 2493223 697160 17093868 20284252 569530 20853782 0 .10 0.12 2 .98 13.01 2313385 678801 16391338 19383524 738110 20121634 0.15 0 .0 7 2.04 15.01 2119735 700743 1 7883156 2 0703632 1 0 68888 2 1772520 0 .20 0.06 1.34 16.47 1852732 700160 18480540 2 1033434 1348367 22381801 0.25 0 .04 0 .8 6 19 .1 7 1671330 658 3 2 3 20100052 2242 9 7 0 4 1619738 2 4049442 0 .30 0.02 0 .5 8 20.97 1467250 617331 20535426 2262 0 0 0 8 1850144 24470152 0.35 0.01 0.31 25.39 1262086 565803 23092794 2 4920682 2 0 12673 26933355 0 .40 0 .0 0 0.14 31 .2 2 1080252 487098 26187316 2775 4 6 6 8 2115476 2 9870144 0.45 0 .0 0 0 .06 36.72 9 08 5 6 7 418982 28255486 2958 3 0 3 6 2195325 31778361 0 .50 0 .0 0 0.00 41 .9 0 746294 354358 29314966 3 0 4 1 5 6 1 8 2218155 3263 3 7 7 3 0.55 0 .0 0 0.00 49.91 610284 276324 3 1 4 2 6 4 9 6 3 2 3 1 3 1 0 6 2179940 3 4493046 0 .6 0 0.00 0.00 54.10 477081 216940 3 0 2 7 7 1 6 8 3 0 9 7 1 1 8 8 2120304 33091492 0.65 0 .00 0.00 58.79 364910 171034 28775764 2 931 1 7 0 8 2032781 3134 4 4 8 9 0 .7 0 0 .00 0.00 64.95 267361 124806 2713 8 7 9 8 27530964 1863438 29394402 0 .8 0 0.00 0.00 77 .2 0 117855 54965 2148 3 0 2 8 2 1 6 5 5 8 4 8 1397541 23053389 0 .9 0 0.00 0.00 88 .7 9 28864 13617 12423358 12465839 773344 1 3239183 0 .9 9 0.00 0.00 98 .6 6 281 142 1 3 93100 1 3 93523 9 0586 1484109 Table 6.20: Conf 1, 40 M bps Link, w = 10, Naive M odel w ith giveup. cost v cv d ly vid dly ftp p e r f voice u til vid eo u til ftp u til to ta l u til to ta l revenu e a b so lu te u til 0 .00 0.16 4.85 12.43 2897972 765750 17399462 21063184 0 21063184 0.01 0.13 4.53 13.25 2773765 8109 6 8 18440312 22025044 77601 22102645 0.03 0.15 3.99 13.89 2 7 05127 789725 19002464 2249 7 3 1 6 192003 22689319 0.05 0 .14 3.56 13.72 2598093 794962 18260250 21653304 382 0 4 8 22035352 0 .08 0.11 2.96 14.25 2 4 77397 767672 18461644 2 1706714 558670 2 2265384 0 .1 0 0.09 2.59 16.49 2333815 770051 20768328 23872196 724939 24597135 0.15 0.06 1.98 16.32 2124334 738284 19440896 22303512 1061629 23365141 0.20 0.03 1.04 18 .6 9 1867758 728571 20962948 2355 9 2 7 6 1338101 2489 7 3 7 7 0.25 0.03 0.80 19 .9 0 1666444 689729 20862000 23218172 1607604 24825776 0 .3 0 0.02 0 .53 23 .2 3 1445604 633900 22748000 24827502 1807984 26635486 0.35 0.01 0 .34 27.66 1252367 554164 25156544 2 6 9 6 3 0 7 6 19 78834 2894 1 9 1 0 0 .4 0 0 .0 0 0.15 3 0 .9 3 1086279 488904 25947036 2 7 5 2 2 2 1 8 21 28872 2965 1 0 9 0 0.45 0 .0 0 0.06 3 6 .8 3 908 5 6 7 418973 28335084 2966 2 6 2 4 2 1 9 3 6 7 7 31856301 0.50 0 .0 0 0 .0 0 41 .9 0 746294 354 3 5 8 29315140 3041 5 7 9 2 2 2 18152 3263 3 9 4 4 0.55 0 .0 0 0 .0 0 49.91 610 2 8 4 276324 31426496 3 2 3 1 3 1 0 6 2 1 79940 3449 3 0 4 6 0.60 0 .0 0 0 .0 0 54 .1 0 477081 216940 30277168 3 0 9 7 1 1 8 8 21 20304 33091492 0.65 0.00 0 .0 0 58.79 364 9 1 0 171034 28775764 2931 1 7 0 8 2032781 3134 4 4 8 9 0.70 0.00 0 .00 64 .9 5 267361 124806 27138798 27530964 1863438 29394402 0.80 0 .00 0 .00 77.20 117855 54965 21483028 21655848 1397541 23053389 0.90 0.00 0 .0 0 88 .7 9 28864 13617 12423358 1246 5 8 3 9 773344 13239183 0.99 0 .0 0 0 .0 0 98 .6 6 281 142 1393100 1 3 9 3 5 2 3 9 0 5 8 6 1484109 Table 6.21: Conf 1, 40 M bps Link, w = 10, Predictive M odel w ith giveup. co st vcv d ly v id d ly ftp p erf voice u til v id e o u til ftp u til to ta l u til to ta l revenu e ab so lu te u til 0.00 2.49 215.67 9.44 1740714 -1 0 5 7 2 3 4 3 13219258 43 87628 0 4 3 87628 0.01 2.49 199.30 9.67 1 7 16577 -9 7 7 6 8 7 2 13462952 5 4 02657 8 1250 5483907 0.03 2.51 191.65 9.46 1614548 -9 3 2 0 5 2 9 12946030 5240050 199056 5439106 0.05 2.05 179.68 9.66 1737353 -8 5 6 3 5 1 3 12871450 60 4 5 2 9 0 393 7 0 6 6438996 0 .0 8 2.29 1 76.49 9.94 1502543 -8 2 7 8 0 6 8 12882283 6 1 0 6 7 5 8 577593 6684351 0 .1 0 1.99 136.78 9.81 1 5 35187 -6 3 0 6 8 3 8 12360355 7588704 759453 8 3 4 8 1 5 7 0.15 1.38 96 .0 7 11 .0 7 1573404 -4 2 4 9 7 4 5 13186140 1 0509799 1087427 11597226 0 .2 0 1.27 67 .2 8 12.78 1389952 -2 725971 14339116 13003097 1380042 14383139 0.25 0 .57 27.78 16.83 1463135 -6 3 3 9 0 3 17648778 1 8478010 1628362 20106372 0 .3 0 0.24 13.24 22.44 1393377 1 4053 21978224 23385654 18 3 5 1 3 7 25220791 0.35 0.31 10.56 23.01 1184071 116770 20929884 22230724 2047728 24278452 0 .4 0 0.04 1.65 29 .4 9 1063890 4 3 8 1 1 7 24739428 2 6241436 2 1 31984 28373420 0.45 0 .08 1.59 34.52 890489 370 5 1 9 26557522 27818530 2 2 33606 30052 1 3 6 0 .5 0 0.01 0 .1 3 4 1 .1 9 743215 3 532 4 0 28814800 29911 2 5 6 2222131 3213 3 3 8 7 0.55 0 .00 0 .0 0 47 .9 7 606944 281361 30208192 31096498 2 191754 33288252 0.60 0 .00 0.00 53.12 477555 219948 2 9729094 30426598 21 3 1 5 6 3 32558161 0.65 0 .00 0 .0 0 58.79 364910 171034 28775764 29311708 2032781 3134 4 4 8 9 0 .7 0 0 .0 0 0.00 64.95 267361 124806 27138798 27530964 18 6 3 4 3 8 29394402 0.80 0 .0 0 0 .00 77.20 117855 54965 21483028 2 1655848 1397541 23053389 0.90 0 .00 0 .0 0 88.79 28864 1 3617 12423358 1 2465839 773344 13239183 0 .99 0 .0 0 0 .0 0 98 .6 6 281 142 1393100 1393523 90586 1484109 Table 6.22: Conf 1, 40 M bps Link, w — 10, Naive M odel w ith nogiveup. vcv v id ftp voice v id eo ftp to ta l to ta l a b so lu te co st d ly dly p erf u til u til u til u til revenu e u til 0.00 0.21 46.06 40.16 2984324 25998 56157336 59167656 0 5916 7 6 5 6 0.01 0.42 17.61 29.51 2830469 602 5 3 9 4104 0 6 4 4 44473652 70532 4454 4 1 8 4 0 .0 3 0 .2 9 11.71 23.33 2748743 6 66 4 0 8 31888940 35304088 185161 3 548 9 2 4 9 0.05 0 .1 6 25.55 45.31 2695263 3 78 2 9 3 6 0 2 5 2 8 4 8 6 3326404 331635 6 3 6 5 8 0 3 9 0 .08 0 .5 0 14.71 22 .7 8 2399278 592824 29495868 3 2487972 5 34 0 9 0 3302 2 0 6 2 0 .1 0 0 .0 9 15.89 49 .1 6 2433550 369 4 5 9 61872880 6 467 5 8 8 8 633 7 7 5 6 5 3 0 9 6 6 3 0.15 0.22 24.99 42.59 2 1 16727 186923 50689860 52993512 916775 53910287 0 .2 0 0 .1 4 10.23 35.69 1897137 467 4 3 8 40025568 4 2390144 1235751 4362 5 8 9 5 0 .2 5 0 .2 7 6 .3 7 32.91 1587804 5 0 9 0 9 7 3450 0 2 3 6 3 6597136 1 4 71020 3 8 0 6 8 1 5 6 0 .3 0 0 .10 4.88 36.81 1 4 38917 467485 3603 8 0 3 6 37944440 1 6 70753 3 961 5 1 9 3 0.35 0 .0 7 2.64 35.66 1245571 4 7 7 2 6 6 3242 6 0 3 4 3 4148872 1 8 92814 3 6 0 4 1 6 8 6 0 .4 0 0.17 7.76 49.96 1019078 244807 41898140 43162024 1 8 49666 4 5 0 1 1 6 9 0 0 .45 0.00 0 .03 36 .7 9 918 0 5 9 4 1 9 6 3 0 28306652 2964 4 3 4 0 2206271 31850611 0 .5 0 0.01 0.12 42.13 756858 352761 29471806 3058 1 4 2 4 2 2 37076 3281 8 5 0 0 0.55 0.00 0 .0 0 47 .9 7 606 9 4 4 281361 30208192 31096498 2191754 3 3288252 0 .6 0 0.00 0 .0 0 53.12 477555 219948 29729094 3042 6 5 9 8 2 1 31563 32558161 0.65 0.00 0.00 58 .7 9 364 9 1 0 171034 28775764 2 9311708 2032781 3134 4 4 8 9 0 .7 0 0 .0 0 0 .0 0 64.95 267361 124806 27138798 27530964 1863438 29394402 0 .80 0.00 0 .0 0 77.20 117855 54965 21483028 2165 5 8 4 8 1397541 2305 3 3 8 9 0 .90 0 .0 0 0 .0 0 8 8 .7 9 28864 13617 12423358 12465839 773344 13239183 0 .99 0.00 0 .0 0 98 .6 6 281 142 1393100 1393523 9 0586 1484109 Table 6.23: Conf 1, 40 M bps Link, w = 10, Predictive M odel w ith nogiveup. | 104 co st vcv d ly v id d ly voice u til vid eo u til to ta l u til to ta l revenue a b so lu te u til 0.00 1.71 95.95 2106863 1326309 3433172 0 3433172 0.01 1.57 84 .8 7 2067009 1323468 33 9 0 4 7 7 73712 3 464189 0 .0 3 1.65 86.78 1991767 1311489 3 3 0 3 2 5 6 182347 3 485603 0.05 1.49 69.39 1905770 1341429 3 2 4 7 1 9 9 361365 3 608564 0.08 1.17 57.31 1783879 1296956 3 0 80835 528922 36 0 9 7 5 7 0 .1 0 1.07 45 .3 8 1710330 1288285 2998615 697723 3 696338 0 .15 0.71 26.66 1511757 1242384 2754141 999 2 0 8 3 753349 0.20 0.60 20.80 1356855 1164858 2521713 1289684 3 8 1 1 3 9 7 0.25 0 .26 8 .98 1216364 1070868 2287232 1540169 3827401 0 .3 0 0 .1 0 3.22 1035499 964 6 4 3 2000142 1727386 37 2 7 5 2 8 0 .35 0 .0 7 1.48 902670 849882 1752552 1896848 36 4 9 4 0 0 0.40 0.01 0 .44 776005 743213 1519218 2 0 31326 3 5 50544 0.45 0.00 0.02 644205 621 2 0 6 1265411 2065793 3 331204 0 .5 0 0 .0 0 0 .00 537035 496415 1033450 2 0 79228 31 1 2 6 7 8 0.55 0 .0 0 0 .00 438473 391 3 4 0 829813 2 0 49500 2 8 79313 0.60 0.00 0 .0 0 348425 320532 668 9 5 7 2026300 26 95257 0.65 0 .00 0 .00 266592 244222 510814 1925525 2436339 o .r o 0 .0 0 0 .00 195597 178259 373856 1 7 62500 2 1 36356 0.80 0 .0 0 0 .00 86323 77471 163794 1 3 26884 1490678 0.90 0.00 0 .0 0 20974 19210 40184 727235 767419 0 .9 9 0 .0 0 0 .0 0 197 180 377 77467 77844 Table 6.24: Conf 2, 55 M bps Link, w = 0.5, Naive M odel w ith giveup. v cv v id voice vid eo to ta l to ta l a b so lu te co st d ly d ly u til u til u til revenu e u til 0 .0 0 1.54 8 4 .2 7 2105716 1482768 3588484 0 3 588484 0.01 1.39 71.86 2063997 1441724 3505721 73023 3578744 0 .0 3 1.46 65.55 1998668 1402460 34 01128 181229 3 582357 0.05 1.26 65.15 1918044 1395742 33 13786 360111 36 7 3 8 9 7 0 .0 8 1.13 52 .1 7 1817915 1381053 3 1 98968 530 8 9 8 3 729866 0 .1 0 0 .8 8 45.45 1719796 1314326 3034122 691 4 2 8 3 725550 0.15 0 .7 3 29 .1 7 1534253 1247479 2781732 992 7 6 4 3 774496 0 .2 0 0 .5 4 21.12 1382543 1167131 2549674 1286485 3 836159 0 .2 5 0 .2 7 8 .59 1203661 1078705 2282366 1 5 31517 3 813883 0 .3 0 0.12 4 .34 1041384 944702 1986086 1723205 3709291 0.35 0.05 1.14 910536 845944 1756480 1 8 91088 3 647568 0 .4 0 0.01 0.65 769039 715215 1484254 1 9 80518 3464772 0.45 0 .0 0 0.02 644205 621206 1265411 2065781 3331192 0 .5 0 0 .0 0 0 .0 0 537035 496415 1033450 2 0 79228 3 112678 0.55 0 .0 0 0 .0 0 438473 391340 829 8 1 3 2 0 49500 2 879313 0 .6 0 0 .0 0 0 .00 348425 320532 6 6 8 9 5 7 2 0 26300 2 695257 0.65 0 .0 0 0 .00 266592 244222 510814 1925525 2436339 0 .7 0 0 .0 0 0 .0 0 195 5 9 7 178259 373 8 5 6 1 7 62500 2 136356 0 .8 0 0 .0 0 0 .00 86323 77471 163794 1326884 1490678 0 .9 0 0 .0 0 0.00 20974 19210 40184 727235 767419 0 .9 9 0 .00 0 .00 197 180 377 7 7467 77844 Table 6.25: Conf 2, 55 M bps Link, w = 0.5, Predictive M odel w ith giveup. 105 v cv v id voice video to ta l to ta l a b so lu te co st d ly dly u til u til u til revenu e u til 0 .0 0 2 .20 196.22 2075707 803720 2879427 0 28 7 9 4 2 7 0.01 1.79 1 46.87 2057287 969200 3026487 73726 3 1 00213 0.03 2.13 169.95 1973409 902822 2876231 181904 3 0 58135 0 .05 1.91 1 21.97 1914054 1007057 2921111 3633 4 0 3284451 0.08 1.70 1 19.38 1815032 975905 2790937 535209 33 26146 0 .1 0 1.90 117.37 1710928 972408 2683336 704642 3 3 87978 0.15 1.37 6 6 .9 3 1514178 1058691 2572869 1009374 3 5 82243 0 .2 0 0 .6 6 33.85 1359712 1090794 2450506 1292335 3742841 0.25 0 .4 0 22.33 1221148 1019514 2240662 1548019 3788681 0 .3 0 0.31 9.50 1033201 958228 1991429 1 746436 3737865 0 .35 0 .0 6 1.63 900064 818612 1718676 1867052 3 5 85728 0 .40 0.02 1.05 768346 706747 1475093 1975124 3 4 5 0 2 1 7 0.45 0 .0 4 0.69 651431 599378 1250809 2061881 3 3 12690 0 .50 0 .0 0 0.00 540134 486613 1026747 2075082 3 1 01829 0.55 0 .0 0 0.00 431058 4015 9 4 832652 2 0 60549 2893201 0 .6 0 0 .0 0 0.00 348425 320532 668 9 5 7 2 0 26300 2 6 95257 0.65 0 .0 0 0 .0 0 266592 244222 510814 1925525 2436339 0 .7 0 0 .00 0.00 195597 178259 3 7 3 8 5 6 1762500 2 1 36356 0 .8 0 0 .00 0.00 86323 77471 163794 1326884 1 4 90678 0 .90 0 .0 0 0.00 20974 19210 4 0184 727235 767419 0 .99 0 .00 0.00 197 180 377 77467 7 7844 Table 6.26: Conf 2, 55 M bps Link, w = 0.5, Naive M odel w ith nogiveup. cost vcv d ly vid dly v oice u til vid eo u til to ta l u til to ta l revenu e a b so lu te u til 0 .0 0 0 .7 7 6 5 .5 8 2142212 1390982 3533194 0 3 5 3 3 1 9 4 0.01 1.27 8 2 .4 8 2078244 1455960 3534204 72782 3 6 0 6 9 8 6 0 .0 3 1.45 90.61 1999835 1437034 34 36869 180574 3 6 1 7 4 4 3 0.05 1.04 6 2 .4 7 1903181 1399239 3 3 02420 353251 3 655671 0 .0 8 1.09 71.45 1 807029 1321872 3128901 523832 3 6 52733 0 .1 0 0.72 39 .5 3 1713071 1346537 3059608 679995 3 7 39603 0.15 0.66 41.01 1497746 1207070 2704816 981658 3 6 86474 0 .2 0 0.73 23.90 1361712 1101399 2463111 1252969 3 7 16080 0 .25 0.40 18.04 1213622 1040652 2254274 1525019 3 7 7 9 2 9 3 0 .30 0.23 9 .6 0 1051997 953644 2005641 1743811 3749452 0 .35 0.03 0.82 899355 799647 1699002 1837768 3 5 3 6 7 7 0 0 .4 0 0.03 0 .64 785952 731810 1517762 2 0 24829 3542591 0.45 0.05 0 .85 649970 592874 1242844 2051801 3294645 0 .5 0 0 .00 0 .0 0 540134 486613 1026747 2075082 3 1 0 1 8 2 9 0.55 0 .00 0 .00 431058 401594 832652 2 0 60549 2893201 0 .60 0.00 0.00 348425 320532 6 689 5 7 2026300 2 6 95257 0.65 0.00 0.00 266592 244222 510814 1925525 2436339 0 .7 0 0.00 0 .00 195597 178259 373 8 5 6 1 7 6 2 5 0 0 2 1 3 6 3 5 6 0 .8 0 0.00 0.00 86323 77471 163794 1326884 1 4 90678 0 .9 0 0.00 0.00 20974 19210 40184 727235 767419 0 .9 9 0 .0 0 0 .00 197 180 377 7 7467 77844 Table 6.27: Conf 2, 55 M bps Link, w = 0.5, Predictive M odel w ith nogiveup. 106 vcv vid voice vid eo toteil to ta l a b so lu te co st d ly dly u til u til u til revenue u til 0 .00 1.08 50.01 2084728 1250791 3 3 35519 0 3335519 0.01 1.03 46.12 2073940 1265447 33 3 9 3 8 7 73768 3413155 0 .03 1.06 4 5 .2 7 1985099 1257032 3242131 181851 3423982 0.05 0.95 39.41 1851252 1 250987 3 1 02239 355 1 1 8 3 4 57357 0 .08 0 .84 35.86 1781948 1250592 30 32540 527159 3559699 0 .10 0.72 26.96 1724292 1229964 2 9 54256 698 0 4 4 3 6 52300 0.15 0.49 16.72 1519650 1 217639 2 7 37289 1002120 3739409 0 .20 0.38 12.11 1361870 1 152766 2 5 14636 1296318 3810954 0.25 0.19 6.58 1196594 1047748 2244342 1520860 3765202 0 .30 0.05 1.89 1058358 916 1 1 8 1974476 1712080 3 686556 0.35 0.03 0 .73 895487 824161 1 7 19648 1868428 3 588076 0.40 0.02 0 .4 7 770166 705704 1475870 1984989 3 460859 0.45 0.00 0.12 652812 616 2 5 8 1 2 69070 2074813 3 343883 0 .5 0 0 .0 0 0 .0 0 536011 530075 1066086 2098958 3 165044 0.55 0.00 0 .00 433479 4 0 6 4 3 7 8 39 9 1 6 2062048 2901964 0.60 0.00 0 .00 348425 320 5 3 2 668 9 5 7 2026300 2 6 95257 0.65 0.00 0 .0 0 266592 244222 510814 1925525 2 4 36339 0.70 0 .0 0 0 .0 0 195597 178259 373856 1762500 2136356 0 .80 0.00 0 .0 0 86323 77471 163794 1326884 1490678 0.90 0.00 0 .00 20974 19210 4 0184 727235 767419 0.99 0 .0 0 0 .0 0 197 180 377 77467 77844 Table 6.28: Conf 2, 55 M bps Link, w = 1, Naive M odel w ith giveup. vcv v id voice vid eo to ta l to ta l a b so lu te cost dly d ly u til u til u til revenue u til 0 .0 0 1.03 44.75 2096168 1396398 3 4 92566 0 3 4 92566 0.01 1.02 42 .0 9 2071446 1405803 34 7 7 2 4 9 73046 3550295 0 .0 3 0.93 40 .4 6 2004349 1359418 3 3 6 3 7 6 7 180569 3544336 0.05 0.88 37.06 1877640 1348709 3 2 26349 353152 3579501 0 .08 0.73 31.02 1811063 1324034 31 3 5 0 9 7 525598 3660695 0 .1 0 0.59 23.00 1718114 1 303078 3 0 21192 690 7 1 9 3711911 0.15 0.44 13.43 1557215 1 233119 2 7 90334 1004399 3 7 94733 0 .2 0 0.41 11.79 1367742 1154778 2 5 22520 1281020 3803540 0.25 0.14 4 .8 7 1196177 1085904 2282081 1516856 3 7 9 8 9 3 7 0 .30 0.08 2.23 1057794 954535 2 0 12329 1733218 3 7 45547 0.35 0.02 0 .5 6 911443 801710 1713153 1870922 3584075 0 .40 0.02 0 .55 767308 722354 1489662 1983478 3 4 7 3 1 4 0 0.45 0.00 0.11 652812 616 2 5 8 1269070 2074756 3 3 4 3 8 2 6 0 .50 0.00 0 .00 536011 530075 1066086 2098958 3 1 6 5 0 4 4 0.55 0 .0 0 0 .0 0 433479 4 0 6 4 3 7 839 9 1 6 2062048 2901964 0 .60 0.00 0 .00 348425 320532 6 6 8 9 5 7 2026300 2 6 95257 0.65 0.00 0 .00 266592 244222 510814 1925525 2436339 0.70 0.00 0 .00 195597 178259 373 8 5 6 1762500 2136356 0.80 0.00 0 .0 0 86323 77471 163794 1326884 1 4 90678 0.90 0.00 0 .0 0 2 0974 1 9210 4 0184 727235 767419 0.99 0.00 0 .00 197 180 377 7 7467 77844 Table 6.29: Conf 2, 55 M bps Link, w = 1, Predictive M odel w ith giveup. 107 co st vcv d ly vid d ly voice u til video u til to ta l u til to ta l revenu e a b so lu te u til 0 .0 0 2.20 1 9 6.22 2036989 2 6210 2063199 0 2 0 63199 0.01 2.38 177.56 1974345 176403 2150748 7 3208 2223956 0.03 2.13 169.95 1936785 224811 2161596 181 9 0 4 2 3 43500 0.05 1.91 1 2 1.97 1881778 516118 2397896 363 3 4 0 2761236 0.08 1.70 1 1 9.38 1786946 503337 2290283 535209 2825492 0 .1 0 1.90 1 1 7.37 1680556 509150 2189706 704642 2 8 94348 0 .15 1.37 66.93 1493527 798659 2292186 1 0 09374 3 301560 0.20 0 .66 33.85 1350315 962638 2312953 1292335 3 605288 0.25 0 .4 0 22.33 1215750 937045 2152795 1548019 37 0 0 8 1 4 0.30 0.31 9 .50 1029308 924505 1953813 1746436 3 700249 0.35 0.06 1.63 899359 813408 1712767 1867052 35 7 9 8 1 9 0.40 0.02 1.05 768126 703591 1 4 71717 1975124 3446841 0.45 0.04 0 .69 651041 597507 1248548 2061881 3 310429 0.50 0.00 0 .00 540134 486610 1026744 2075082 31 0 1 8 2 6 0.55 0.00 0 .00 431058 401594 832652 2060549 2893201 0.60 0.00 0 .00 348425 320532 6 68 9 5 7 2026300 2 6 9 5 2 5 7 0.65 0.00 0 .00 266592 244222 510814 1925525 2 4 36339 0.70 0.00 0 .00 195597 178259 373856 1762500 2 1 3 6 3 5 6 0.80 0.00 0 .00 86323 77471 163794 1326884 1 4 9 0 6 7 8 0.90 0 .0 0 0 .00 20974 19210 40184 727235 767419 0.99 0.00 0 .0 0 197 180 377 77467 77844 Table 6.30: Conf 2, 55 M bps Link, w = 1, Naive M odel w ith nogiveup. co st vcv dly v id d ly voice u til v id eo u til to ta l u til to ta l revenue a b so lu te u til 0.00 0.31 70.69 2 167429 1164845 3 3 3 2 2 7 4 0 33 3 2 2 7 4 0.01 0.85 60 .2 8 2062885 1401159 3 4 64044 70744 35 3 4 7 8 8 0 .0 3 0.82 7 2 .3 7 2022315 1360475 3 3 82790 175857 3 5 5 8 6 4 7 0.05 0 .6 7 45 .8 9 1917223 1358896 3 2 7 6 1 1 9 346 6 9 4 3 622813 0.08 1.11 53.87 1812333 1268868 3081201 5 22 5 6 0 3603761 0 .1 0 0 .4 8 35 .1 8 1718566 1273775 2992341 6 6 3 0 3 4 3 655375 0.15 0 .6 0 29.66 1524320 1167058 2691378 9 7 6 8 9 0 3 668268 0.20 0.41 23.82 1343503 1065413 2408916 1250636 3659552 0 .2 5 0 .24 9 .5 0 1200591 1003883 2204474 1511364 3 715838 0.30 0 .1 9 7.66 1047558 927332 1974890 1731244 3 7 0 6 1 3 4 0.35 0 .03 0 .8 6 895295 832 8 0 4 1728099 1846977 3 5 7 5 0 7 6 0.40 0.01 1.20 759202 714080 1473282 1988368 3 4 6 1 6 5 0 0 .45 0 .0 0 4.25 648640 574741 1223381 2 0 42556 32 6 5 9 3 7 0.50 0 .0 0 0 .0 0 540134 486610 1026744 2075082 31 0 1 8 2 6 0.55 0 .0 0 0 .0 0 431058 401594 832652 2 0 60549 2893201 0 .60 0 .00 0.00 348425 320532 668957 2026300 2 695257 0.65 0 .00 0.00 266592 244222 510814 1925525 2436339 0 .70 0 .00 0.00 195597 178259 373856 1762500 2 1 36356 0 .80 0 .0 0 0.00 86323 77471 163794 1326884 1490678 0 .90 0 .00 0.00 20974 1 9210 40184 727235 767419 0 .99 0 .00 0.00 197 180 377 77467 77844 Table 6.31: Conf 2, 55 M bps Link, w — 1, Predictive M odel w ith nogiveup. 108 co st vcv d ly v id d ly voice u til video u til to ta l u til to ta l revenue a b so lu te u til 0.00 0 .33 11.46 2076281 1108610 3184891 0 3184891 0.01 0 .33 10.14 2019488 1122688 3142176 73034 3 2 1 5 2 1 0 0.03 0.28 8 .69 1950374 1138675 3 089049 179809 3 2 68858 0.05 0.25 7.62 1875359 1154760 3030119 355588 3 3 8 5 7 0 7 0 .08 0 .29 7.18 1748445 1147500 2895945 522918 3 4 18863 0 .1 0 0 .20 5.68 1659230 1 1 42236 2801466 679891 3 4 8 1 3 5 7 0.15 0 .14 3.71 1518086 1128348 2646434 994549 3 6 40983 0 .20 0.10 2.18 1341011 1086536 2 4 2 7 5 4 7 1268050 3 6 9 5 5 9 7 0.25 0 .0 7 1.85 1193277 9982 8 9 2191566 1527776 3719342 0 .30 0 .03 0.58 1024143 9247 8 9 1948932 1698397 3 6 4 7 3 2 9 0.35 0.01 0.29 903080 832900 1735980 1886233 3 6 2 2 2 1 3 0 .4 0 0 .00 0 .0 7 771161 716102 1487263 1998918 3486181 0.45 0 .00 0.02 646 3 9 7 598254 1244651 2042084 3 2 86735 0 .50 0.00 0.00 531294 486752 1018046 2061862 3 0 79908 0.55 0 .00 0.00 427967 423632 851599 2 073904 2 9 25503 0 .60 0.00 0.00 348425 320532 668 9 5 7 2026300 2 6 95257 0.65 0 .00 0 .0 0 266592 244222 510814 1925525 2436339 0 .70 0 .00 0.00 195597 178259 373856 1762500 2 1 36356 0 .80 0.00 0 .0 0 86323 77471 163794 1326884 1490678 0.90 0 .00 0 .00 20974 19210 40184 727235 767419 0 .99 0 .00 0.00 197 180 377 77467 77844 Table 6.32: Conf 2, 55 M bps Link, w = 5, Naive M odel w ith giveup. co st vcv dly vid d ly voice u til vid eo u til to ta l u til to ta l revenu e a b so lu te u til 0 .00 0 .2 7 9 .4 7 2062084 1177417 3239501 0 3239501 0.01 0.25 10.01 2029803 1 2 78190 3 3 07993 71641 3 3 79634 0 .0 3 0 .28 8 .96 1979022 1262532 3241554 178645 3 4 2 0 1 9 9 0.05 0 .2 7 6 .7 7 1823882 1289013 3112895 348041 3 4 60936 0 .0 8 0 .18 6.15 1796143 1270940 3067083 519108 3586191 0.10 0 .1 7 4 .80 1690539 1244839 2935378 675612 3 6 1 0 9 9 0 0 .15 0.11 3.52 1497685 1185486 2683171 977462 3 6 6 0 6 3 3 0 .2 0 0 .0 7 2.24 1371367 1118245 2489612 1277992 3 7 6 7 6 0 4 0.25 0.05 1.37 1198560 1033406 2231966 1506887 37 3 8 8 5 3 0 .3 0 0 .03 0 .7 6 1029516 929955 1959471 1697002 3 6 5 6 4 7 3 0 .35 0.01 0.22 916857 820252 1737109 1 8 83699 3 6 2 0 8 0 8 0 .4 0 0 .0 0 0 .0 6 767909 693152 1461061 1949722 34 1 0 7 8 3 0 .45 0 .00 0.01 646397 598254 1244651 2041881 3286532 0.50 0 .0 0 0 .00 531294 486752 1018046 2061862 3 079908 0 .55 0 .00 0.00 427967 423632 851599 2 0 73904 2925503 0 .6 0 0 .00 0 .00 348425 320532 6 68 9 5 7 2 0 26300 2695257 0.65 0 .0 0 0 .00 266592 244222 510814 1925525 2436339 0 .70 0 .00 0.00 195597 178259 373856 1762500 2136356 0 .80 0 .00 0 .00 86323 77471 163794 1326884 1490678 0 .9 0 0 .00 0 .00 20974 19210 40184 727235 767419 0 .99 0 .00 0.00 197 180 3 7 7 77467 77844 Table 6.33: Conf 2, 55 M bps Link, w = 5, Predictive M odel w ith giveup. co st vcv dly vid dly voice u til vid eo u til to ta l u til to ta l revenu e a b so lu te u til 0.00 2.20 196.22 1727237 -6193871 -4 4 6 6 6 3 4 0 -4 4 6 6 6 3 4 0.01 2.38 177.56 1641549 -5 3 84098 -3 742549 73208 -3669341 0 .0 3 2.61 181.00 1573949 -5 5 8 2 7 6 6 -4 0 0 8 8 1 7 182793 -3 8 2 6 0 2 4 0.05 1.91 121.97 1623570 -3 4 11400 -1 7 8 7 8 3 0 363340 -1 4 2 4 4 9 0 0 .0 8 1.70 119.38 1562255 -3 2 77204 -1 7 1 4 9 4 9 535209 -1 1 7 9 7 4 0 0.10 1.90 1 1 7.37 1437579 -3196915 -1 7 5 9 3 3 6 704642 -1 0 5 4 6 9 4 0.15 1.37 66.93 1328321 -1 2 8 1 5 9 7 46724 1009374 1056098 0 .2 0 0.66 33.85 1275142 -6 2 6 1 3 1212529 1292335 2504864 0.25 0 .40 22.33 1172566 277297 1 4 49863 1 5 4 8 0 1 9 2997882 0.30 0.31 9.50 998 1 6 7 654720 1652887 1 7 46436 3 3 99323 0.35 0.06 1.63 893 7 1 9 771778 1665497 1867052 35 3 2 5 4 9 0 .4 0 0.02 1.05 766370 678341 1444711 1 9 75124 3419835 0.45 0.04 0.69 647925 582542 1230467 2061881 32 92348 0 .5 0 0 .0 0 0.00 540134 486 5 8 7 1026721 2075082 3 1 01803 0.55 0.00 0.00 431058 401594 832652 2 0 60549 2893201 0 .60 0 .0 0 0.00 348425 320532 6689 5 7 2026300 2695257 0.65 0 .0 0 0.00 266592 244222 510814 1925525 2 436339 0 .7 0 0 .0 0 0 .00 195597 178259 373856 1 7 62500 2136356 0 .80 0 .0 0 0 .00 86323 77471 163794 1326884 1490678 0 .9 0 0.00 0 .00 20974 1 9210 40184 727235 767419 0 .99 0 .0 0 0 .0 0 197 180 377 77467 77844 Table 6.34: Conf 2, 55 M bps Link, w = 5, Naive M odel w ith nogiveup. co st vcv dly v id dly voice u til vid eo u til to ta l u til to ta l revenu e a b so lu te u til 0 .0 0 0 .24 28.74 2103241 845 6 3 8 2948879 0 2 948879 0.01 0.54 22.14 2060602 1134368 3 1 94970 67031 3262001 0.03 0 .4 8 21.68 1970590 1194835 3165425 171021 3 336446 0.05 0 .32 18.53 1912766 1118175 3030941 326031 3356972 0 .0 8 1.46 17.47 1611860 1077702 2689562 483693 3 173255 0.10 0 .2 6 13.11 1714287 1088534 2802821 6 3 2 9 6 6 34 3 5 7 8 7 0.15 0 .12 11.71 1523922 977178 2501100 912 1 4 0 3 413240 0 .2 0 0 .2 7 8.04 1372928 965502 2338430 1 2 05807 35 4 4 2 3 7 0.25 0 .1 9 8 .15 1173640 852 8 6 7 2026507 1 4 78314 3504821 0 .3 0 0 .0 4 2.19 1031691 881782 1913473 1 6 68930 3 5 82403 0.35 0.02 0 .6 6 892 6 7 0 815 0 4 8 1707718 1 8 47019 3 5 5 4 7 3 7 0 .4 0 0.00 0 .10 769420 680 4 7 9 1449899 1954674 3 4 04573 0.45 0.00 2.67 653799 521318 1175117 20 00814 3175931 0 .5 0 0 .0 0 0 .00 540134 486 5 8 7 1026721 2075082 3 1 01803 0.55 0.00 0 .00 431058 401594 832652 2060549 2893201 0 .6 0 0 .00 0 .00 348425 320532 668 9 5 7 2026300 2 6 95257 0.65 0 .0 0 0 .00 266592 244222 510814 1925525 2436339 0 .7 0 0.00 0 .00 195597 178259 373856 1762500 2 1 36356 0 .8 0 0.00 0 .00 86323 77471 163794 1326884 1490678 0 .9 0 0 .0 0 0 .0 0 20974 19210 40184 727235 767419 0 .9 9 0.00 0 .0 0 197 180 377 7 7467 77844 Table 6.35: Conf 2, 55 M bps Link, w = 5, Predictive M odel w ith nogiveup. cost vcv dly vid d ly voice u til video u til to ta l u til to ta l revenue a b so lu te u til 0.00 0.16 4.71 2029554 1077249 3106803 0 3 1 06803 0.01 0.14 4.21 2026081 1 1 07749 3133830 72774 3206604 0 .0 3 0.14 4.02 1931502 1111523 3043025 178737 3221762 0.05 0.12 3.08 1902299 1124389 3026688 356851 3 3 8 3 5 3 9 0 .0 8 0.12 3.11 1742316 1119436 2861752 519323 3 3 81075 0 .1 0 0.10 2.44 1680696 1122998 2803694 6843 0 8 3 4 8 8 0 0 2 0.15 0 .0 7 1.80 1512278 1097288 2609566 990535 3600101 0 .2 0 0 .04 1.04 1337824 1089512 2427336 1268486 3695822 0.25 0.02 0.59 1193077 1031502 2224579 1518523 3743102 0 .3 0 0.01 0 .2 7 1036740 935986 1972726 1707779 3 6 80505 0.35 0 .00 0 .1 7 892951 829 3 4 0 1722291 1880633 3602924 0.40 0 .00 0 .0 3 774476 734510 1508986 1 998307 3 5 07293 0.45 0 .00 0.00 645521 633794 1279315 2081800 33 61115 0 .5 0 0 .00 0 .0 0 533392 503573 1036965 2072124 3 1 09089 0.55 0 .00 0.00 432039 388446 820485 2020141 2840626 0.60 0 .00 0.00 348425 320532 668957 2026300 26 95257 0.65 0 .00 0.00 266592 244222 510814 1925525 2436339 0.70 0 .00 0.00 195597 178259 3738 5 6 1762500 2136356 0 .8 0 0 .0 0 0.00 86323 77471 163794 1326884 1490678 0.90 0 .00 0.00 20974 19210 40184 727235 767419 0 .9 9 0 .00 0.00 197 180 377 77467 77844 Table 6.36: Conf 2, 55 M bps Link, w = 10, Naive M odel w ith giveup. vcv vid voice v id eo to ta l to ta l a b so lu te co st d ly d ly u til u til u til revenu e u til 0.00 0.11 4 .0 7 2060196 1258913 3 3 19109 0 33 1 9 1 0 9 0.01 0 .1 0 3.62 2004602 1292539 3297141 71072 3 3 68213 0.03 0.12 3 .66 1969388 1 2 19979 3 1 89367 178120 33 6 7 4 8 7 0.05 0.12 3.11 1854415 1209670 3064085 349680 3 4 13765 0.08 0.09 2.81 1776058 1238223 3014281 515529 3529810 0 .10 0 .0 7 2.29 1684463 1196778 2881241 678 8 6 8 3 560109 0.15 0.04 1.41 1519747 1178604 2698351 979123 3677474 0 .2 0 0.03 1 .10 1350289 1107075 2457364 1258765 3 716129 0.25 0.02 0.72 1186868 1 0 46637 2233505 1515224 3 748729 0.30 0.01 0.21 1039291 949934 1989225 1702634 3 691859 0.35 0.01 0.15 897121 862170 1759291 1904797 3 664088 0.40 0.00 0 .04 775231 712458 1487689 1993266 3480955 0.45 0.00 0 .00 645521 633794 1279315 2081633 3 360948 0.50 0.00 0 .00 533392 503573 1036965 2072124 3 109089 0.55 0 .00 0 .00 432 0 3 9 388446 820485 2020141 2840626 0.60 0 .00 0 .00 348425 320532 668 9 5 7 2026300 2695257 0.65 0 .0 0 0 .00 266592 244222 510814 1925525 2436339 0 .7 0 0.00 0 .00 195597 178259 373856 1762500 2136356 0 .8 0 0.00 0 .00 86323 77471 163794 1326884 1490678 0 .9 0 0.00 0 .00 20974 19210 40184 727235 767419 0.99 0 .0 0 0.00 197 180 377 77467 77844 Table 6.37: Conf 2, 55 M bps Link, w = 10, Predictive M odel w ith giveup. co st vcv d ly v id d ly voice u til video u til to ta l u til to ta l revenue a b so lu te u til 0 .00 2.20 196.22 1340048 -13968971 -1 2 6 2 8 9 2 3 0 -126 2 8 9 2 3 0.01 2.38 177.56 1225553 -12334725 -11109172 73208 -110 3 5 9 6 4 0.03 2.61 1 81.00 1123260 -12700623 -115 7 7 3 6 3 182793 -11 3 9 4 5 7 0 0.05 1.91 1 21.97 1300809 -8 320796 -7 0 1 9 9 8 7 363340 -6 6 5 6 6 4 7 0 .0 8 1 .70 119.38 1281392 -8 002880 -6 7 2 1 4 8 8 535209 -6 1 8 6 2 7 9 0 .1 0 1.90 117.37 1 1 33857 -7 8 29495 -6 6 9 5 6 3 8 704642 -5 9 90996 0.15 1.37 66.93 1121814 -3 881916 -2760102 1009374 -1 750728 0 .20 0.66 33.85 1181176 -1 344177 -163001 1292335 1129334 0.25 0 .4 0 22.33 1118585 -547389 571196 1548019 2119215 0 .3 0 0.31 9.50 959240 317488 1276728 1746436 3023164 0.35 0.06 1.63 886668 719741 1606409 1867052 3473461 0 .4 0 0.02 1.05 764175 646779 1410954 1975124 3386078 0.45 0 .0 4 0 .69 644031 563835 1207866 2061881 3 2 69747 0 .5 0 0.00 0 .00 540134 486558 1026692 2075082 3 1 01774 0.55 0 .0 0 0 .00 431058 401594 832652 2 0 60549 2893201 0 .60 0.00 0 .0 0 348425 320532 668957 2026300 2695257 0.65 0 .0 0 0.00 266592 244222 510814 1925525 2436339 0 .70 0.00 0 .0 0 195597 178259 373856 1762500 2136356 0 .8 0 0.00 0 .0 0 86323 77471 163794 1326884 1490678 0 .9 0 0.00 0 .0 0 20974 19210 40184 727235 767419 0 .9 9 0 .0 0 0.00 197 180 377 7 7467 77844 Table 6.38: Conf 2, 55 M bps Link, w = 10, Naive M odel w ith nogiveup. v cv vid voice video to ta l to ta l a b so lu te co st d ly dly u til u til u til revenue u til 0.00 0.26 14.93 2071545 793090 2864635 0 2864635 0.01 0.31 13.85 2042344 1004069 30 4 6 4 1 3 63371 3 1 09784 0 .03 0.45 12.69 1934017 1130956 30 6 4 9 7 3 165646 3 2 30619 0.05 0.21 20 .9 7 1889757 606434 2496191 299670 2795861 0 .0 8 0.61 14.72 1650892 782929 2433821 4 443 8 9 2878210 0 .1 0 0 .1 4 16.91 1737600 674315 2411915 576137 2988052 0.15 0.25 26.32 1479901 147381 1627282 808122 2435404 0.20 0 .04 15.53 1 3 98917 409734 1808651 1137298 2945949 0 .25 1.03 8 .5 9 927612 572825 1 5 00437 1374335 2874772 0 .3 0 0 .1 0 2.28 1024024 845042 1869066 1683293 3552359 0 .35 0 .0 3 2.20 892545 6856 4 7 1578192 1777602 3355794 0 .40 0.00 6 .0 9 767796 353341 1 1 21137 1960383 3 0 8 1 5 2 0 0.45 0.00 0.20 644834 586948 1231782 2007647 3 2 3 9 4 2 9 0 .50 0.00 0.00 540134 486558 1026692 2074995 3 1 0 1 6 8 7 0.55 0.00 0.00 431058 401594 832652 2060549 2893201 0 .60 0.00 0.00 348425 320532 6 689 5 7 2026300 2 6 9 5 2 5 7 0.65 0.00 0 .0 0 266592 244222 510814 1925525 2436339 0 .70 0.00 0 .0 0 195597 178259 373856 1762500 2136356 0 .80 0.00 0 .0 0 86323 77471 163794 1326884 1490678 0 .90 0 .00 0.00 20974 19210 40184 727235 767419 0 .99 0 .00 0 .0 0 197 180 377 77467 77844 Table 6.39: Conf 2, 55 M bps Link, w = 10, Predictive M odel w ith nogiveup. 112 6.3 Reservationless Network Model In this section we form ulate a m odel to study how charging affects u tility in a reser vationless m ultiple service class network. In th e previous m odel, netw ork congestion was driven by a cost based, elastic, dem and function. In this m odel we analyze a sim ple netw ork where load is held constant and the d ata pipe size is varied to reflect different levels of network congestion. We utilize the two priority netw ork model previously defined in C hapter 4.3 consisting of four application types: Telnet, Voice, F T P , and Em ail. We also make use of utility functions defined in C hapter 4.2 where each application has a specific function designed to capture the essential character istics of its netw ork service requirem ents. In C hapter 4.3.6, we dem onstrated th a t priority pricing was superior to flat pricing. T h at study fixed th e high priority price, P high, and set th e low priority price, piow, such th a t th e to tal revenue equaled 100. The constant revenue condition is not required when trying to determ ine w hether charging increases absolute utility because we are not evaluating the effectiveness of a pricing policy as m uch as we are ] evaluating th e effectiveness of charging verses not charging. T he m odel discussed in this section does not use flat pricing to generate revenue in the free network. In the absence of pricing, absolute u tility in the network is ju st the sum of th e perform ance m easures, i.e. V , where n equals the to tal num ber of applications, because there is no cost com ponent. I T he objective in this section is to show th a t charging users can increase total u tility w ithout regard to a constant revenue condition. We com pare th e to tal utility generated in a free network to th a t generated in a cost network. In th e absence of charging in a m ultiple service class network, users are not m otivated to select priorities th a t correspond to their applications’ requirem ents. We assum e th a t given a choice between two priority classes in a free network, users selfishly select highj priority. This behavior fails to m axim ize to tal utility because applications t h a t , are m ost sensitive to perform ance fail to benefit from th e technological advantages | available through m ultiple service class networks. I We adopt th e following pricing policy in the cost network. Initially set Phigh — t ! I Plow = 0 and slowly increase P high, he. fix p\ow = 0 V Phigh- For each phigh (and; Plow = 0), check for th e existence of a Nash Equilibrium . T h a t is, given a price; we atte m p t to find a single priority setting th a t each user class will selfishly, i.e. independently, select com pared to all others. We evaluate the to tal utility for all priority com binations. Upon finding a point of Nash Equilibrium , we record the to tal utility, utility for th e individual users, priority setting, and revenue generated. As previously described in th e reservation oriented netw ork, we briefly define a redistribution policy for the reservation oriented network model. Once again redis trib u tio n is difficult because it introduces num erous incentive problem s. In order to avoid influencing user behavior, the redistribution policy m ust be exogenous to I netw ork usage. T he redistribution received by user x would have to be independent of their decision to use the network and cannot be based on th e am ount of money th a t they spent. Low priority users will always require redistribution since their perform ance is always worse in th e priority based netw ork because their packets are pushed to th e back of th e queue. In the event th a t high priority users require redistribution, the pool from which their redistributions are taken m ust exclude the portion they spent. High priority users would require redistribution equal to the difference in th eir current utility and th a t in the free network (plus some small e). Section 6.3.1 provides th e results of our analysis. 6.3.1 E v a lu a tio n o f th e R e se r v a tio n le ss N etw o rk M o d e l Section 6.3 illustrated our reservationless m odel in its m ost general form. This subsection presents our analysis of the reservationless network m odel using several specific network and end-user applications. T he previous reservation oriented m odel and the reservationless netw ork model are very sim ilar in term s of increased utility. In b o th models an excessive num ber of users causes to tal u tility to decrease. In the form er m odel users are forced to wait before obtaining service b u t the service is guaranteed once granted. T he latter] m odel adm its all users; however, the perform ance m easures degrade rapidly as the link utilization approaches 100%. Call setup is delayed in the first m odel while i packets are delayed in the second model. j i We exam ine th e same seven network configurations previously described in Chap-1 ter 4.3.5. These configurations covered a diverse range of one and two way network! configurations. T he network topologies can be found in Figures 4.1 — 4.3 while the link spd kbps pri set ting price per MB Uxelnet Uvoice U f t p UEmail d iff U TR TU 570 2222 2211 1211 0.00000 0.32000 0.88000 -3.940 -1.847 -3.957 -295.33 -12.398 -32.817 112.26 112.02 112.03 -1.290 -1.294 -1.294 0.242 0.228 0.000 12.902 32.088 -188.30 96.480 73.964 670 2222 2221 2211 1211 0.00000 0.16000 0.24000 0.44000 -2.203 -2.015 -1.514 -2.209 -189.63 -101.54 -9.431 -16.723 165.88 185.12 165.52 165.54 -0.757 -11.949 -0.760 -0.759 11.192 0.362 0.352 0.000 47.324 9.677 16.044 -26.703 69.616 153.819 145.848 1070 2222 2221 1211 0.00000 0.02100 0.16000 -0.802 -0.765 -0.804 -13.606 -3.914 -6.423 247.92 277.99 247.76 -0.281 -1.877 -0.282 1.596 0.164 0.000 6.211 5.834 233.229 271.436 240.249 1270 2222 2221 0.00000 0.01200 -0.656 -0.645 -2.361 -1.320 263.78 287.82 -0.219 -1.109 0.890 0.000 3.549 260.539 284.747 2000 2222 2221 0.00000 0.00070 -0.543 -0.536 -0.572 -0.580 226.17 233.45 -0.153 -0.205 0.060 0.000 0.207 224.898 232.133 5000 2222 2221 2121 1121 0.000000 0.000004 0.000032 0.000244 -0.515 -0.515 -0.515 -0.516 -0.512 -0.512 -0.513 -0.513 105.97 106.03 106.03 105.98 -0.127 -0.127 -0.127 -0.127 0.0003 0.0012 0.0024 0.000 0.001 0.008 0.062 104.816 104.880 104.878 104.823 Table 6.40: Increased U tility Table for Conf 1 on Network Topology A. traffic com position and aggregate traffic levels can be found in Tables 4.2 — 4.8 and 4.9 respectively. Tables 6.40 — 6.46 contain the results of our analysis. Each table contains the following data: link speed, priority setting,1 2 price per m egabyte, Telnet perfor-l m ance, Voice perform ance, F T P perform ance, Em ail perform ance, d iff U,13 total revenue ( T R ), and to tal u tility {TU). T he free network has a priority setting of 2222, indicating th a t all applications requested high priority service. 12As described in Chapter 4, each character refers to the priority setting of an application. A 1 indicates low priority service and a 2 indicates high priority service. The application’s priorities) are listed from left to right in the following order: Telnet, Voice, FTP, and Email. For example,' 2211 refers to a network configuration where Telnet and Voice request high priority service whilej ] FT P and Em ail request low priority service. 13diff U refers to the sum of the difference in utility when applications in the priority run are; worse off than applications in the free network. ! 115! 1 link spd kbps pri set ting price per MB UTelnet Uy oice UpTP VEmail diff U TR TU 670 2222 2221 2211 1211 0.00000 0.50000 0.64000 1.16000 -7.810 -4.821 -4.850 -8.030 -390.82 -90.541 -32.761 -58.671 69.05 94.56 68.80 68.81 -4.709 -101.4 -4.729 -4.728 96.702 0.276 0.481 0.000 123.18 35.841 57.803 -334.29 -102.22 26.455 -2.618 870 2222 2221 1211 0.00000 0.04000 0.42000 -2.632 -1.434 -2.645 -135.48 -7.694 -21.716 134.88 203.20 134.62 -1.582 -8.747 -1.586 7.165 0.272 0.000 9.854 20.929 -4.812 185.322 108.677 1070 2222 2221 1211 0.00000 0.02000 0.30000 -1.515 -1.107 -1.520 -45.328 -2.777 -15.692 167.05 216.81 166.87 -0.913 -3.654 -0.916 2.741 0.228 0.000 4.927 14.949 119.289 209.270 148.743 1270 2222 2221 0.00000 0.02000 -1.145 -1.006 -9.596 -1.830 183.21 220.87 -0.661 -2.266 1.605 0.000 4.927 171.806 215.770 2000 2222 2221 0.00000 0.00080 -0.842 -0.807 -0.757 -0.733 163.71 176.55 -0.418 -0.573 0.155 0.000 0.197 161.691 174.439 4000 2222 2221 2121 1121 0.000000 0.000008 0.000075 0.000408 -0.778 -0.777 -0.777 -0.779 -1.164 -1.162 -1.168 -1.168 97.02 97.34 97.35 97.29 -0.231 -0.232 -0.232 -0.232 0.001 0.005 0.006 0.000 0.002 0.013 0.071 94.844 95.169 95.174 95.114 Table 6.41: Increased U tility Table for Conf 2 on Network Topology A. link spd kbps pri set ting price per MB U'Tetnet Uvoice Uf t p UEmail d iff U TR TU 670 2222 2211 1211 0.00000 0.44000 0.74000 -5.522 -3.702 -5.558 -544.78 -37.980 -62.819 83.868 83.305 83.331 -2.514 -2.533 -2.533 0.582 0.592 0.000 39.244 61.276 -468.95 39.089 12.420 870 2222 2221 1211 0.00000 0.06000 0.32000 -2.032 -1.602 -2.045 -164.37 -32.678 -27.897 138.114 179.364 137.563 -0.888 -6.829 -0.894 5.941 0.570 0.000 15.884 26.498 -29.177 138.255 106.728 1070 2222 2221 1211 0.00000 0.02000 0.26000 -1.313 -1.113 -1.319 -52.435 -5.653 -22.856 163.901 202.718 163.557 -0.571 -2.989 -0.573 2.418 0.352 0.000 5.295 21.529 109.582 192.964 138.809 1270 2222 2221 0.00000 0.02000 -1.031 -1.008 -13.627 -3.309 181.242 209.291 -0.423 -1.775 1.352 0.000 5.296 166.162 203.199 2000 2222 2221 0.00000 0.00090 -0.819 -0.805 -1.299 -1.311 165.684 174.129 -0.275 -0.388 0.125 0.000 0.238 163.291 171.626 4000 2222 2221 2121 1121 0.000000 0.000008 0.000075 0.000408 -0.778 -0.777 -0.777 -0.779 -1.164 -1.162 -1.168 -1.168 97.016 97.340 97.350 97.293 -0.231 -0.232 -0.232 -0.232 0.001 0.005 0.006 0.000 0.002 0.013 0.071 94.844 95.169 95.174 95.114 Table 6.42: Increased U tility Table for Conf 3 on Network Topology A. 116' I link spd kbps pri set ting price per MB Uxelnet U v oice UFt p UEmail diff U T R T U 300 2222 2211 1211 0.00000 0.44000 2.46000 -15.475 -3.774 -15.620 -295.71 -15.758 -83.897 44.499 41.643 42.597 -3.521 -3.729 -3.790 3.064 2.316 0.000 17.424 82.985 -270.20 18.382 -60.709 450 2222 2211 1211 0.00000 0.24000 0.62000 -4.486 -2.385 -4.516 -112.31 -8.823 -21.641 193.133 191.772 191.979 -0.948 -0.955 -0.954 1.386 2.007 0.000 9.504 20.915 75.392 179.609 164.868 650 2222 2211 1211 0.00000 0.16000 0.20000 -2.009 -1.818 -2.020 -43.178 -6.032 -7.381 257.732 256.131 256.267 -0.468 -0.471 -0.471 1.604 1.479 0.000 6.336 6.747 212.077 247.810 246.395 1050 2222 2221 0.00000 0.01400 -1.041 -1.040 -2.160 -1.155 299.483 317.117 -0.237 -1.359 1.122 0.000 3.990 296.045 313.562 2000 2222 2221 0.00000 0.00080 -0.804 -0.800 -0.546 -0.568 238.609 243.315 -0.149 -0.207 0.080 0.000 0.228 237.110 241.740 4000 2222 2221 2121 1121 0.000000 0.000002 0.000024 0.000319 -0.775 -0.775 -0.775 -0.776 -0.515 -0.515 -0.516 -0.516 132.358 132.484 132.481 132.411 -0.131 -0.131 -0.131 -0.131 0.0003 0.0014 0.0025 0.000 0.001 0.006 0.078 130.937 131.063 131.060 130.988 Table 6.43: Increased U tility Table for Conf 4 on Network Topology A. link spd kbps pri set ting price per MB UTelnet Uvoice Uf t p UEmail diff U T R T U 570 2222 2211 1211 0.00000 0.32000 0.92000 -6.723 -3.163 -6.753 -418.56 -19.342 -52.969 89.986 89.308 89.364 -2.226 -2.236 -2.236 0.688 0.662 0.000 19.915 51.562 -337.52 64.567 27.406 670 2222 2211 1211 0.00000 0.26000 0.42000 -3.700 -2.744 -3.715 -279.33 -15.884 -24.851 149.496 148.788 148.788 -1.230 -1.236 -1.236 0.714 0.729 0.000 16.181 23.539 -134.76 128.924 118.987 1070 2222 2221 1211 0.00000 0.02100 0.10000 -1.428 -1.374 -1.430 -24.661 -7.981 -6.737 238.432 258.619 238.062 -0.456 -2.754 -0.457 2.298 0.373 0.000 7.888 5.605 211.887 246.510 229.438 1270 2222 2221 0.00000 0.01100 -1.225 -1.197 -5.753 -2.037 241.952 258.513 -0.363 -1.474 1.111 0.000 4.132 234.611 253.805 2000 2222 2221 0.00000 0.00100 -1.028 -1.022 -1.069 -1.102 203.799 208.090 -0.258 -0.364 0.139 0.000 0.376 201.443 205.601 5000 2222 2221 2121 1121 0.000000 0.000005 0.000033 0.000228 -0.984 -0.984 -0.984 -0.985 -0.978 -0.977 -0.979 -0.979 92.784 92.854 92.854 92.791 -0.225 -0.225 -0.225 -0.225 0.001 0.001 0.002 0.000 0.002 0.010 0.071 90.598 90.668 90.666 90.602 Table 6.44: Increased U tility Table for Conf 5 on N etwork Topology B. link spd kbps pri set ting price per MB Uxelnet Uvoice Uf t p UEmail diff U TR TU 570 2222 2221 1211 0.00000 0.22000 0.46000 -8.140 -6.639 -8.183 -581.81 -179.49 -54.081 236.88 284.91 236.29 -4.576 -74.23 -4.594 69.72 0.651 0.000 115.12 50.787 -357.65 24.555 169.432 670 2222 2221 1211 0.00000 0.06000 0.28000 -5.496 -4.019 -5.521 -351.08 -87.369 -33.995 282.89 375.65 282.52 -3.019 -18.643 -3.028 15.624 0.399 0.000 31.387 30.914 -76.705 265.621 239.977 1070 2222 2221 0.00000 0.01100 -2.716 -2.680 -6.432 -3.938 348.95 382.37 -1.199 -2.596 1.397 0.000 5.759 338.603 373.115 1270 2222 2221 0.00000 0.00430 -2.700 -2.601 -6.405 -3.198 350.80 385.06 -1.193 -2.596 1.403 0.000 2.251 340.502 376.663 2000 2222 2221 0.00000 0.00040 -2.459 -2.446 -2.528 -2.540 283.95 291.63 -0.954 -1.056 0.114 0.000 0.209 278.007 285.589 5000 2222 2221 2121 1121 0.000000 0.000002 0.000018 0.000153 -2.390 -2.389 -2.389 -2.390 -2.369 -2.368 -2.370 -2.370 125.82 125.88 125.88 125.82 -0.864 -0.865 -0.865 -0.865 0.0007 0.0017 0.0022 0.000 0.001 0.007 0.061 120.191 120.259 120.254 120.198 Table 6.45: Increased U tility Table for Conf 6 on Network Topology C. link spd kbps pri set ting price per MB UTelnet Uy oice Uf t p UEmail diff U TR TU 300 2222 2211 1211 0.00000 0.50000 1.60000 -32.862 -13.937 -33.343 -1015.6 -90.986 -278.40 262.58 259.74 260.27 -18.959 -19.387 -19.334 3.27 3.17 0.000 94.122 272.61 -804.87 135.430 -70.806 400 2222 2211 1211 0.00000 0.38000 0.60000 -14.784 -11.160 -14.898 -602.10 -69.678 -107.16 415.77 413.78 413.87 -8.433 -8.488 -8.486 2.043 2.064 0.000 71.533 102.23 -209.544 324.454 283.330 650 2222 2221 1211 0.00000 0.04000 0.22000 -5.863 -5.172 -5.882 -113.21 -25.110 -41.609 576.87 672.00 575.86 -3.374 -17.276 -3.385 13.90 1.045 0.000 30.232 37.484 454.425 624.441 524.981 1000 2222 2221 0.00000 0.01200 -4.022 -3.942 -7.925 -5.945 607.95 659.14 -1.983 -4.293 2.310 0.000 15.112 594.016 644.954 2000 2222 2221 0.00000 0.00020 -3.450 -3.438 -3.500 -3.521 453.59 460.82 -1.375 -1.431 0.077 0.000 0.151 445.267 452.434 3000 2222 2221 2121 1121 0.000000 0.000007 0.000027 0.000392 -3.398 -3.394 -3.394 -3.401 -3.405 -3.404 -3.408 -3.408 318.30 318.79 318.79 318.58 -1.301 -1.304 -1.304 -1.304 0.003 0.006 0.009 0.000 0.005 0.015 0.222 310.196 310.686 310.679 310.463 Table 6.46: Increased U tility Table for Conf 7 on Network Topology C. i I 118! We analyze u tility both in term s of the individual application classes and for the entire population. For all link speeds and configurations, we were able to find at least one priority setting and subsequent price th a t had a point in N ash Equilibrium .1 4 W ith m any link speeds we found several such points. Each entry in the table represents one Nash equilibrium point. Once a Nash equilibrium point is found for a given price, there are m any subsequent equilibrium prices for th e current priority setting. If we were to choose a higher equilibrium price, then due to th e increased cost, th e to tal revenue would increase at th e expense of th e utility for high priority applications. Ideally we could choose the highest price th a t still showed an increase in utility for all high priority applications com pared to the free run. This price would m axim ize to tal revenue, T R , while still assuring th a t all high priority applications were b e tter off. F urther in all cases the to tal utility was higher th an the corresponding run in the free network. Usually for very small increases in price the to tal u tility was m uch higher. T he T R colum n lists th e level of revenue generated from high priority users at each Nash equilibrium point. We note th a t both th e price per m egabyte and TR (total revenue) decrease as the link speed increases. This phenom enon results from our decision to hold offered load constant while studying various levels of netw ork congestion. As th e link speed increases th e level of network congestion decreases, thereby, reducing th e perform ance gains achievable through proper application of our m ultiple service class network. W hen considering utility for th e individual applications, th e evaluation requires considerably m ore explanation. 1 In all instances th e low priority applications were slightly worse off in th e cost netw ork when com pared to the sam e application in the free network. This outcom e was expected. In the free network all applications request high priority; therefore all applications com pete equally for network resources. In th e cost netw ork appli cations request both high and low priorities. A pplications requesting low priority] do so because of the lower cost service (in our analysis low priority traffic is free); therefore, in the cost netw ork these applications no longer com pete equally for net- ] work resources causing their perform ance m easures to degrade when com pared to] I 14The tables only contain the first price for each link speed and priority setting at which Nash j equilibrium occurs. i 119 th e free network. Therefore, since cost is not a factor, the resulting utility for low priority applications in the cost network will be lower th an th a t in the free network. In nearly all instances, the utility for high priority applications was higher than th a t in the free network. In several instances a high priority voice user experienced a lower u tility in th e cost netw ork.1 5 All anomalous conditions occurred when the Nash equilibrium point included a high priority voice application w ith a link u ti lization below 25%.16 Further, this phenom enon only occurs when at least two applications requested high priority service. In a relatively uncongested network, applications do not experience large perform ance gains through prioritization of traffic, so any perform ance gains available to voice users were obscured by the pres ence of other high priority users. In cases when a high priority voice application had a lower u tility th an in th e corresponding application in the free network, th e high priority price at Nash equilibrium was too high com pared the perform ance gain. The following form ula represents this condition for a given voice user v. jjp r io r ity ^ j j f r e e (6.48) y p r i o r i t y _ C v < y j r e e + q ( g 4 9 ) C v > V P ^ o r i t y _ y j r e e ( g g g ) where C v equals the cost calculated from p h ig h at Nash equilibrium , y v r% o rity denotes the high priority perform ance m easure for application v in the cost network, and V j ree denotes th e perform ance m easure for application v in the free network. We assert th a t all users can be m ade effectively b etter off by im plem enting some form a direct redistribution such as th a t indicated in the beginning of Section 6.3. In all instances the to tal revenue generated ( TR) was higher th an the loss in utility experienced by th e individual applications ( d iff £/), i.e. T R > d iff U, V Nash equilib rium points. In m ost cases th e total revenue was much greater. Low priority users always required redistribution. Thus, a redistribution policy based on some form I of uniform distribution could suffice as long as th e redistribution is paid w hether or j not user x chooses to use the network. High priority voice users have two ad d itio n al' 15Consider the voice application at the 2221 priority setting of Configuration 1 with a link speed of 2000Kbps. Its utility decreases from -0.572 in the free network to -0.580 in the cost network. 16Actual link utilizations are provided in Tables 4.10 — 4.16. 120 com plications. F irst, they only require redistribution when selecting high priority service and th e netw ork load is below 25%. So the redistribution policy would have to take into account statistically determ ined traffic p atterns. Second, since they ipay for netw ork services, the pool from which their redistributions are taken m ust exclude the portion they spent. In the event th a t their utility was lower in th e cost netw ork, they would require redistribution equal to th e difference in their current u tility and th a t in th e free network (plus some small e). We hope to formalize a m odel in future work. 6.4 Conclusion In this chapter we exam ined the effects of pricing in two classes of netw ork models: reservation oriented and reservationless networks. The reservation oriented network m odels were constructed from analytical queueing models w ith elastic dem and. We also studied a broader set of reservation oriented netw ork models through sim ula tion. T he reservationless network models were constructed from our study of user incentives taken from C hapter 4. In this model, we held offered load constant and varied th e d ata pipe size. Charging provided users an incentive to select the prior ity m ost appropriate for their application. Throughout our pricing study, we found th a t charging increases u tility in the presence of redistribution. We also specified th e conditions under which charging increased utility before redistribution. Our goal in conducting this study was to show th a t th e externality created by charging had a greater effect th an the charge itself, thereby, increasing absolute utility. Chapter 7 Summary and Extensions D on’ t tell me how hard you work. Tell me how much you get done. — Jam es J. Ling This dissertation studied user incentive and pricing issues in com puter com m u nications networks. We proposed several reservation oriented and reservationless network models to analyze m icroeconomic principles related to price theory, u tility theory and resource allocation. We dem onstrated the effectiveness of our models by showing th a t network efficiency gains were possible by increasing th e to tal satisfac tion in th e network. In the following sections we briefly sum m arize our contributions and provide a practical perspective of our work. We also discuss direction for future research. 7.1 Significance of Work This dissertation has brought together issues from disparate fields. We have char acterized netw ork com ponents as scarce resources and outlined several approaches which sought to m axim ize to tal utility in th e network. In p articular we have dem onstrated th a t m ultiple service class networks require graduated prices in order to m axim ize the technological advantages offered by such 122 system s. In th e absence of graduated prices, users lacked incentive to choose a lower priority because it failed to m axim ize their individual perform ance. O ur analysis showed th a t all sim ulated users preferred a graduated pricing scheme to a flat pricing scheme. Moreover, we dem onstrated th a t given a two priority netw ork m odel and priority pricing scheme, users selfishly selected the optim al service discipline when trying to m axim ize their own utility. This effect was desirable because it created a strategic equilibrium known in economics as Nash Equilibrium where no individual user would have had an incentive to deviate from their current service selection. F urther, we achieved th e highest possible utility for th e entire netw ork since we selected th e m axim al sum ( V opt) after evaluating all possible priority com binations. We identified two price ranges: acceptable and adoptable. T he acceptable price range was defined by prices th a t satisfy the Nash condition. T he adoptable pricing scheme addressed the political viability of a new pricing policy. If no one would lose by th e adoption of a new pricing policy, it is less likely to run into political opposition. This price range was defined in our sim ulations by th e price space m aking priority pricing superior to flat pricing. We conducted a quantitative analysis studying th e interaction of netw ork conges tion and price. We analyzed four applications: Telnet, Voice, F T P , and Email. For each application type, we docum ented th e network dynam ics and changes in total u tility th a t occurred for small increases in price. T he results were consistent w ith our expectations, helping to support our hypothesis th a t the essential characteristics of th e various network services were captured. We exam ined the effect of incorporating a simple usage sensitive pricing policy on increasing to tal utility. We analyzed two cases. We first studied utility in a free netw ork and then we incorporated a charge and studied the subsequent effects on user utility. O ur analysis included two classes of netw ork models. T he first class consisted of sim ple reservation oriented single and m ultiple class networks while th e \ second class consisted of m ultiple class reservationless networks. In the first class! of models we im plem ented an elastic dem and function w here offered load was function of price. T he charge served to tu rn back a fraction of th e population w ith ’ lower benefits so th a t users w ith higher benefits experience less delay in obtaining | netw ork service, thereby, experiencing increased utility. In th e second class of m od els, we held offered load constant and varied the d ata pipe size. In these models th e charge provided users an incentive to select th e priority m ost appropriate for their application. T he objective in both classes was to specify th e conditions in which charging increased utility. In general, we found th a t some form of revenue redistribution was required in order to increase total utility. This result indicated th a t the external effect im posed by charging1 was greater th an the charge itself such th a t the to tal population experienced increased utility. 7.2 Practical Perspective of Work We hope th a t this dissertation encourages further research and discussion related to pricing in large scale, integrated, com puter com m unications networks. We should reiterate th a t pricing can refer to forms of incentives other th an money; for instance, one can price service in term s of adm inistrative incentives such as quotas or logs. W hile our fram ework can be generalized to these other forms of pricing, for th e sake of sim plicity we referred only to m onetary incentives in this work. This dissertation has continually em phasized the im portance of im plem enting a usage sensitive pricing structure. We will briefly revisit this discussion in contrast to the flat per byte m odel and the current pricing practice in th e Internet, which is based on fixed fee depending on the d ata pipe size. Priority based usage-sensitive charging contains two subcom ponents, the first is th e am ount of usage and the second is the QoS. A flat per byte model, such as th e one used in C hapter 4, has the form er b u t not th e latter. Users are assessed a charge based on the volume of traffic sent; however, there is no notion of the traffic type. T he In te rn et’s practice of using a fixed fee according to the pipe size attem pts to crudely approxim ate paying by QoS. This pricing structure, although not flat for all custom ers, fails to capture the! I volume sensitive subcom ponent outlined above. It is tru e th a t the pipe size limitsj peak rate and th e applications th a t can be supported by a given pipe size; however, | this does not justify pricing based solely on pipe size. T he network would become j — --------------------------------------------------------------------------------------------------------------------------------- I 1The external effects are to discourage users with smaller benefits from using the network and) to create an incentive that will at tim es encourage users to select lower priorities , overloaded if all users were to continuously transm it at their peak rates. In this case, one of two outcomes are likely a) the network is over engineered to adequately handle th e load, which would have as a side effect high prices, or b) there are not enough subscribers such th a t th e network is underutilized, which would also result in high prices. One could think of physical pipe size as the type of service one gets over a very different tim e scale, i.e. during th e whole period th a t th e pipe size is in effect, rath er than ju st the active transm ission tim e. O ur analysis suggests th a t b oth subcom ponents, i.e. QoS and am ount of usage, are equally im portant. T here is a large and rapidly growing body of work on th e design of m ulticlass service disciplines for high-speed d ata networks supporting a wide range of service requirem ents [16, 25, 74]. There are m any different approaches to m eeting these service requirem ents, and they differ in some profound ways (such as guaranteed QoS classes, reserving bandw idth for datagram traffic, etc.) th a t will have significant im plications for netw ork perform ance and user incentives. In C hapter 4 we analyzed a sim ple two priority network th a t required two graduated prices. Future high-speed networks will m ost certainly offer a greater num ber of service classes requiring a m ore complex incentive com patible pricing structure. One exam ple would be to offer users layered encoding for video applications. T he user’s fee stru ctu re would be based on the desired quality of th e video stream . There is surprisingly little literature on the relationship betw een network per form ance and application perform ance. Those studies th a t have been done focused on voice [53]. In addition to voice, we have characterized prim itive perform ance m etrics for video, Telnet, FT P, and Em ail in reservation oriented and reservation less networks. One of th e points of our work is to apply these perform ance m etrics to netw ork perform ance under different loads, service disciplines, and traffic com positions in order to m easure relative user satisfaction. These perform ance m etrics m ust be tailored to th e underlying service discipline and user population w ithin thej ! context of the proposed network and user environm ents. We believe charging should be an im portant design consideration in future, in- j tegrated, packet switched, com puter com m unications networks. This research pro-j vides network designers a m ethodology for evaluating end user utility in th e presence! of other design a n d /o r policy considerations. We have dem onstrated th a t priority! 125! pricing is superior to flat pricing and th at charging w ith redistribution is better th an not charging at all. We addressed theoretical issues related to user incentives in m ultiple class n e t works. There m ay be other practical m ethods th a t can approxim ate th e theoretical objectives. Specifically, future network designs need to m im ic user incentive signals th a t will encourage efficient use. T h at is, a large group of self interested hetero geneous users will need a m echanism allowing them to adjust their perform ance based on existing network conditions. This m echanism m ust be designed such th at users will self select to some network-wide optim al condition. Or, if such control is not available at the user level, then predefined static or statistical priorities m ust be identified and im plem ented. We did not address th e m any im plem entation and protocol support issues th a t arise in the context of any usage sensitive pricing sys tem s. Future netw ork designs m ust provide adequate m echanism s to im plem ent such policies. We m ention this analysis Section 7.3 describing direction for future work. Finally, we would like to address several issues concerning how users should be charged. T h at is, should there be a setup charge?2 a charge per packet? a charge for dropped packets? We will address each issue in turn. We have not incorporated a setup charge into our models; however, incorporating such a tw o-part price structure would only require trivial m odifications to our approach. This analysis has been extensively studied in the telephone industry. A tw o-part rate structure would be applicable in the context of a reservation oriented netw ork model. In this model, the netw ork actually incurs a cost associated w ith establishing a connection much like in a telephone network. We will further address this issue in the context of future work. O ur current belief is th a t charging per packet is not necessary. We m ake this statem ent for th e following reasons. F irst, accounting procedures m ay become too costly and cumbersome. Second, statistical approxim ation and sam pling can be used j to accurately m easure usage. Third, traffic flows in guaranteed QoS networks have 2Some network protocols require a setup procedure prior to using the associated network service, j For exam ple, the telephone network requires connection establishm ent before a conversation m a y ' j begin. This process is usually transparent to the end user; however, their is always a fixed cost ■ associated with the process. < I 126' flow specifications established at connection setup th a t can be m onitored an d /o r enforced by policies such as those identified in [3, 19, 51, 74], There are issues such as authentication and spoofing th a t m ust be confronted; however, these im plem entation issues are not explicitly addressed in this dissertation. We also feel it is unnecessary to credit users for dropped packets. Users should be charged for all resources they consume. The drop rate is a function of the user’s explicit priority class. If the drop rate is excessive then it should be reflected in th e price allocated to this priority class. R utenburg et al. [58] provide a com prehensive analysis of charging users in the presence of packet loss. Next, we present directions for future work. 7.3 Future Work This dissertation opens two avenues for future work. T he first relates to theoretical extensions to our current models while th e second pertains to im plem entation issues not addressed in this work. We first consider possible extensions to our models. We selected utility functions th a t captured essential characteristics of the services. These functions allowed us to m ake qualitative statem ents regarding th e interplay betw een a pricing policy and a service discipline; however, they failed to capture the tru e relationship between application perform ance and network service. Refinement of th e u tility functions will allow a m ore in depth study of th e relationship between application and network perform ance. This relationship has not been extensively studied in th e literature. A nother possible extension would be to incorporate a form of peak load pricing into our queueing analysis sim ilar to those proposed in [2, 52]. This would provide users w ith additional incentives to distribute their service requests in tim e and allow j | for greater efficiency gains in th e network. We could also study th e incorporation of a setup charge sim ilar to th a t used in the telephone industry. It is also possible | to study th e effects m ulticast [18] would have on to tal utility. O ther possible ex- j tensions to our queueing analysis include proving our analysis holds for a general j 127! benefit distribution, proving th a t the single service class predictive m odel never in creases total u tility prior to redistribution, and form alizing a revenue redistribution methodology. These extensions would provide a m ore robust analysis. The second area for continued work concerns im plem entation issues not ad dressed in this dissertation. In developing networks for the future, network design ers m ust provide adequate mechanisms to im plem ent m onetary and perform ance incentives. Recent discussion of resource usage feedback m echanisms has identified several, som ew hat independent design choices, for example: feedback channel (e.g., m onetary, adm inistrative), feedback policy (e.g., based on type of service delivered or priority), granularity (e.g., charge back to end users or to institutions for ag gregate traffic) [22]. We have not addressed th e m any im plem entation and protocol support issues th a t arise in the context of any usage sensitive pricing system. Two of th e m ost critical protocol support issues th a t m ust be investigated are au diting/m onitoring and authentication. T he form er issue is of im portance in order to properly capture the users’ usage and behavior pattern s required to accurately cal culate charges or to enforce/establish quotas. A uditing can occur at m any places in th e network, i.e. entry point, exit point, and interm ediate gateways [22, 58]. Proper placem ent and granularity of auditing m echanisms is crucial to both network and application perform ance. Any attem p t to distribute pricing or usage inform ation w ithout incorporating some form of authentication is pointless. A uthentication is required to insure th a t sensitive inform ation is delivered from credible sources. Such investigations as discussed in this section are needed before any practical application of our work can be realized. 7.4 Conclusion We believe th a t this dissertation represented the first com prehensive, publicly avail-1 able analysis of charging in m ultiple service class networks. O ur analysis prim arily addressed microeconomic principles of utility theory, price theory, and resource allo cation applied to th e study of integrated com puter com m unications networks. Our goal was to provide a m echanism to increase efficiency and hence to tal utility orj happiness in th e network. | 128 i We studied th e issues of pricing and user incentives in a variety of reservation oriented and reservationless networks. We found th a t user incentives were necessary to balance perform ance incentives so th a t m ultiple service class networks would ( have th e desired effect. We also addressed the interplay betw een congestion and price sensitivity for a variety of applications m ost likely to be found in futuristic integrated networks. Finally, we constructed a num ber of queueing and sim ulation models designed to analyze the effect of charging on to tal u tility in the network. We considered both elastic and fixed dem and models. We found th a t th e external effect im posed by charging, nam ely discouraging users w ith sm aller benefits from using th e network, was greater th an th e charge itself such th a t th e to tal population experienced increased utility. We believe th a t user incentive policies such as charging will be an im portant de sign consideration in th e future of integrated com puter com m unications networks. A goal in conducting this research was to dem onstrate th a t charging for services served a greater purpose th an merely raising revenue for th e service providers. Our analysis shows th a t charging can also be beneficial to the heterogeneous user com m unity at large. Reference List [1] Frederick T. Andrews. T he evolution of digital loop carrier. IE E E Com m uni cations M agazine, 29(3):31-35, M arch 1991. [2] P eter A rnott, A ndre D ePalm a, and Robin Lindsey. A structural m odel of peak period congestion: A traffic bottleneck w ith elastic dem and. To appear in: The Am erican Economic Review, 1992. [3] J.J. Bae and T. Suda. Survey of traffic control schemes and protocols in ATM networks. In Proceedings IE E E , volume 79, February 1991. [4] U. Bagchi. A note on linearly decreasing, delay-dependent non-preem ptive priority queue discipline. Operations Research, 32:952-957, July-A ugust 1984. [5] U. Bagchi and R. Sullivan. Dynam ic, non-preem ptive priority queues w ith general, linearly increasing priority function. Operations Research, 33:1278- 1298, Nov.-Dee. 1985. [6] K.R. B alachandran. Purchasing priorities in queues. M anagem ent Science, 18(5):319— 326, 1972. [7] Bell Telephone Labs, AT&T. Engineering and Operations in the Bell System, 1986. [8] R. Bohn. Industrial response to spot electricity prices: Some em pirical evi dence. W orking P aper M IT-EL-80-016W P, M IT Energy Laboratory, February 1980. [9] M. Boiteux. Peak load pricing. Journal o f Business, 33(2):157-179, April 1960. I [10] A ndreas Bovopoulos and Aurel Lazar. Decentralized algorithm s for optim al j flow control. In Proceedings o f the 25th Annual Allerton Conference on Com- ■ munication, Control, and Computing, Septem ber 1990. ] [11] M.C. Caram anis, R.E. Bohn, and F.C. Schweppe. O ptim al spot pricin g :! P ractice and theory. IE E E Transactions on Power Apparatus and System , ! 101(9):3234-3245, 1982. i [12] Hung-po Chao and R obert W ilson. P riority service: Pricing, investm ent, and m arket organization. The Am erican Econom ic Review, 77(5):899-916, Decem ber 1987. [13] Thom as M. Chen, Jean W alrand, and David G. M esserschm itt. Dynam ic pri ority protocols for packet voice. IE E E Journal on Selected Areas in C om m u nications, 7(5):632-643, June 1989. [14] Renu C hipalkatti, Jam es Kurose, and Don Towsley. Scheduling policies for real-tim e and non-real-tim e traffic in a statistical m ultiplexer. In Proceedings IE E E INFO CO M , pages 774-783, 1989. [15] Israel Cidon and Inder S. Gopal. Paris: An approach to integrated high-speed private networks. International Journal o f Digital and Analog Cabled System s, 1:77-85, 1988. [16] David D. Clark, Scott Shenker, and Lixia Zhang. Supporting real-tim e appli cations in an integrated services packet network: A rchitecture and mechanism. In Proceedings o f SIG CO M M . ACM, Septem ber 1992. [17] Ron Cocchi, D eborah E strin, Scott Shenker, and Lixia Zhang. A study of pri ority pricing in m ultiple service class networks. In Proceedings o f SIGCO M M . ACM, Septem ber 1991. [18] Steve Deering. M ulticast routing in internetw orks and extended LA N ’s. In Proceedings o f SIG CO M M , pages 55-64. ACM, A ugust 1988. [19] A lan Demers, Srinivasan Keshav, and Shenker Scott. Analysis and sim ulation of a fair queueing algorithm . In Proceedings o f SIG CO M M . ACM, Septem ber 1989. [20] Jacques H. Dreze. Some postw ar contributions of french econom ists to theory and public policy. The Am erican Economic Review, 1964. [21] R ichard A. Elnicki and W arren R. Hughes. An em pirical analysis of dem ands for priority com puting goods by externally and internally funded researchers. Journal o f Business, 53(1):79— 96, 1980. j [22] D eborah E strin and Lixia Zhang. Design considerations for usage account ing and feedback in internetw orks. A C M Com puter Com m unication Review, 20(5):56-66, O ctober 1990. [23] Donald F. Ferguson. The Application o f Microeconomics to the Design o f Re- j source Allocation and Control Algorithms. PhD thesis, G raduate School of A rts' and Sciences, Colum bia University, 1989. [24] Domenico Ferrari. Client requirem ents for real-tim e com m unication services. IE E E Com m unications M agazine, pages 65-72, November 1990. [25] Domenico Ferrari and Dinesh C. Verma. A scheme for real-tim e channel estab lishm ent in wide-area networks. IE E E Journal on Selected Areas in Com m u nications, 8(3):368-379, April 1990. [26] M. G hanbari. Two-layer coding of video signals of V B R networks. IE E E Journal on Selected Areas in Com m unications, 7(5):771-781, June 1989. [27] P. Jr. Green. An introduction to network architectures and protocols. IE E E Transactions on Com m unications, 28(4):413-424, April 1980. [28] G arrett H ardin. The tragedy of the commons. Science, 162:1243-1248, De cem ber 13 1968. [29] M an-Tung Hsiao and Aurel Lazar. A game theoretic approach to optim al decentralized flow control of m arkovian queueing networks w ith m ultiple con trollers. In Proceedings o f Perform ance ’ 87, pages 279-285, Decem ber 1987. Brussels, Belgium. [30] Jay M. H ym an, Aurel A. Lazar, and Giovanni Pacifici. Joint scheduling and adm ission control for ATS-based switch nodes. In Proceedings o f SIGCOM M . ACM, Septem ber 1992. [31] G unnar Karlsson and M artin V etterli. Packet video and its integration into th e netw ork architecture. IE E E Journal on Selected Areas in Com munications, 7(5):739-751, June 1989. [32] Leonard Klienrock. Queueing System s, Volume II: Com puter Applications. John W iley and Sons, 1976. [33] D avid Kreps. A Course in Microeconomic Theory. Princeton U niversity Press, 1990. [34] J.F . Kurose, D. Towsley, and H.G. Schulzrinne. Scheduling policies for sup porting real-tim e traffic in w ide-area com puter networks. In First International W orkshop on Network and Operating System s Support fo r Digital Audio and Video. International C om puter Science In stitu te, November 1990. TR-90-062 Berkeley, CA. [35] Aurel A. Lazar and Giovanni Pacifici. Control of resources in broadband n et works w ith quality of service guarantees. IE E E Com m unications Magazine, 29(10), O ctober 1991. 132 i [36] Youngo Lim and John Kobza. Analysis of a delay-dependent priority discipline in a m ulti-class traffic packet switching node. In Proceedings IE E E IN FO C O M , pages 889-898, 1988. [37] A rthur Y. Lin and John A. Silvester. Priority queueing strategies and resource allocation protocols for traffic control at an atm integrated broadband switch ing system . Technical R eport CSI-90-11-02, U niversity of Southern California Com m unications Sciences Institute, 1990. [38] R ichard G. Lipsey and P eter O. Steiner. Economics. H arper & Row, sixth edition, 1981. [39] J.C . Luetchford. C C IT T recom m endations-netw ork aspects of th e ISDN. In Proceedings o f the International Conference on Com munications, pages 1067- 1071, June 1985. [40] E. M alinvaud. C apital accum ulation and efficient allocation of resources. Econometrica, 21(2):233-268, 1953. [41] Allison M ankin. Random drop congestion control. In Proceedings o f SIG COMM , pages 1-7. ACM, Septem ber 1990. [42] M .G. M archand. Priority pricing. M anagement Science, 20(7):1131-1140, M arch 1974. [43] Eric M askin. Theory of im plem entation in nash equilibrium . In Hurwicz Schmeidler and Sonnenschein, editors, Social Goals and Social Organization, pages 173-204, Septem ber 12-14, 1985. [44] N. M atsuo, M. Youito, and Y. Tokunga. Packet interleaving reducing speech quality degradation in packet voice com m unications. In Proceedings IE E E G LO BECO M , pages 45.4.1-45.4.12, December 1987. [45] Bridger M. M itchell and Ingo Vogelsang. Telecommunications Pricing Theory and Practice. Cam bridge U niversity Press, 1991. [46] Bisw anath M ukherjee. Integrated voice-data com m unication over high-speed fiber optic networks. IE E E Computer, 24(2):49-58, February 1991. < [47] John Nagle. On packet switches w ith infinite storage. IE E E Transactions on\ Communications, 35:435-438, 1987. [48] P. Naor. On regulation of queue size by levying tolls. Econometrica, 37:15-24, J 1969. ; i [49] John Nash. Equilibrium points in n-person games. In Proceedings o f the Na-' tional Academy o f Sciences, pages 48-49, 1950. < [50] W alter Nicholson. Microeconomic Theory Basic Principles and Extensions. D ryden Press, fourth edition, 1989. [51 [52 [53 [54 [55 [56 [57 [58 [59 [60 [61 A bhay K um ar Parekh. A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks. PhD thesis, D epartm ent of E lectri cal Engineering and C om puter Science, M assachusetts In stitu te of Technology, February 1992. LIDS-TH-2089. Colin Parris, Srinivason Keshav, and Domenico Ferrari. A framework for the study of pricing in integrated networks. Tenet Group, C om puter Science Divi sion, UC Berkeley, 1992. D avid P etr, Luiz DaSiliva, and V ictor Frost. Priority discarding of speech in in tegrated packet network. IE E E Journal on Selected Areas in Com munications, 7(5):644-656, June 1989. J. Pfanzagl. Theory o f Measurement. Wiley, 1968. Jon Postel. User datagram protocol. Request For Com m ents 768, Inform ation Sciences Institute, University of Southern California, A ugust 1980. Jon Postel. Transmission control protocol. Request For Com m ents 793, Infor m ation Sciences Institute, U niversity of Southern California, Septem ber 1981. L. Roberts. The evolution of packet switching. In Proceedings IE E E , pages 1307-1313, November 1978. V lad R utenburg and R ichard G. Ogier. Fair charging policies and minimum- expected-cost routing in internets with packet loss. In Proceedings IE E E IN- FOCOM , pages 279-288, 1991. Beverly Sanders. An incentive com patible flow control algorithm for rate based allocation in com puter/com m unications networks. In Proceedings o f the 6th IE E E Distributed Com puter System s Conference, pages 314-320, May 1986. P aul W . Shum ate and R ichard K. Snelling. Evolution of fiber in th e residential loop plant. IE E E Com munications M agazine, 29(3):68-74, M arch 1991. I N. Singer, H. K anter, and A. Moore. Prices and the allocation of com puter [ tim e. Proceedings A F IP S Fall Joint Com puter Conference, pages 493-498, | 1968. I [62] K. Sriram and D.M. Lucantoni. Traffic sm oothing effects of bit dropping in j a packet voice m ultiplexer. In Proceedings IE E E INFO CO M , pages 8 A .l.l-j 8A.1.12, 1988. j 134 [63] A ndrew S. Tanenbaum . Computer Networks. Prentice-H all, second edition, 1988. [64] W .S. Torgerson. Theory and Methods o f Scaling. Wiley, 1958. [65] Laurence H. Tribe. Policy sciences: Analysis or ideology? Philosophy & Public A ffairs, 1(1):3-21, 1971. [66] Jon ath an S. Turner. New directions in com m unications (or which way to the in form ation age?). IE E E Com munications Magazine, 24(6):8-15, O ctober 1986. [67] D etlof vonW interfeldt and W ard Edwards. Decision Analysis and Behavioral Research. Cam bridge University Press, 1986. [68] P atrick E. W hite. The broadband ISDN, th e next generation switching system. In Proceedings IE E E IC C , 1986. [69] P atrick E. W hite. The role of the broadband integrated services digital network. IE E E Com m unications Magazine, 29(3):116-119, M arch 1991. [70] R obert W ilson. Efficient and com petitive rationing. Econometrica, 57(1): 1— 40, January 1989. [71] U. Yechiali. C ustom ers’ optim al joining rules for th e g i/m /s queue. Manage m ent Science, 18(7):434-448, 1972. [72] Nanying Yin, San-qi Li, and Thom as E. Stern. D ata perform ance in an inte-, grated packet voice/data system using voice congestion control. In Proceedings IE E E G LO B E COM, pages 517-521, 1988. [73] Chin Yuan and John A. Silvester. Queueing analysis of delay constrained voice traffic in a packet switching system . IE E E Journal on Selected Areas in Com m unications, 7(5):729-738, June 1989. [74] Lixia Zhang. V irtual clock: A new traffic control algorithm for packet switching networks. In Proceedings o f SIGCOM M . ACM, Septem ber 1990. 1 [75] Lixia Zhang, Scott Shenker, and David D. Clark. Observations on th e dynamics! of a congestion control algorithm : The effects of two-way traffic. In Proceedings o f SIG CO M M , pages 133-147. ACM, Septem ber 1991. i

Linked assets