University of Southern California Dissertations and Theses

Accounting and access control for multicast distributions: Models and mechanisms

(USC Thesis Other)

Accounting and access control for multicast distributions: Models and mechanisms

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content INFORM ATION TO USERS This manuscript has been reproduced from the microfilm master. UMI films the text directly from the original or copy submitted. Thus, some thesis and dissertation copies are in typewriter free, while others may be from any type of computer printer. The quality of this reproduction Is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleedthrough, substandard margins, and improper alignment can adversely afreet reproduction. In the unlikely event that the author did not send UMI a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. Oversize materials (e.g., maps, drawings, charts) are reproduced by sectioning the original, beginning at the upper left-hand comer and continuing from left to right in equal sections with small overlaps. Each original is also photographed in one exposure and is included in reduced form at the back of the book. Photographs included in the original manuscript have been reproduced xerographically in this copy. Higher quality 6” x 9” black and white photographic prints are available for any photographs or illustrations appearing in this copy for an additional charge. Contact UMI directly to order. UMI A Bell & Howell Information Company 300 North Zed) Road, Ann Arbor MI 48106-1346 USA 313/761-4700 800/521-0600 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A C C O U N T IN G A N D ACC ESS CO NTRO L FO R M ULTICAST D IST R IB U T IO N S: M ODELS A N D M E C H A N ISM S by Shai Herzog A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (Computer Science) August 1996 Copyright 1996 Shai Herzog Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 9705108 UMI Microform 9705108 Copyright 1996, by UMI Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. UMI 300 North Zeeh Road Ann Arbor, MI 48103 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UNIVERSITY OF SOUTHERN CALIFORNIA THE GRADUATE SCHOOL UNIVERSITY PARK LOS ANGELES. CALIFORNIA 90007 This dissertation, written by H E R zoC r s m r ......... under the direction of hlS 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 ,raduate Studies Date DISSERTATION COMMITTEE Chairperson Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Acknowledgm ents First and foremost, I would like to express my deepest appreciation to my advisor, Dr. Deborah Estrin for her guidance, friendship and great contribution to my matu rity as a researcher. The privilege and pleasure of working with her for the last five years cannot be easily described; perhaps a single word, “m om ” , so frequently used by her students could best describe her nurturing and caring educational approach. Dr. Scott Shenker has been my academic co-advisor for the last three years. Scott’s Scholarship reminds me of a quote attributed to Voltaire: “ perfection is attained by slow degrees; it requires the hand of tim e” . Indeed, Scott has shown me how patience, foresight, self criticism and a lot of hard work could turn initial ideas into solid results. 1 wish to thank the members of my qualifying and dissertation committee. Bob Felderman, Clifford Neumann, John Silvester, and Dennis McLeod. In particular, I would Hke to thank Bob Felderman for supporting and encouraging my early research work. Cliff Neumann for his scrutiny and tough questions, and John Silvester for his insightful comments. My three years at US C/Information Sciences Institute working on the RSVP project have been a valuable learning experience. I would like to thank the many RSVP collaborators who helped me grow as a researcher. Among the many, 1 would like to thank Lixia Zhang, Dave Clark and John Wroclawski; my special thanks to Robert Braden for giving me the opportunity to pursue my research interests within the RSVP project. (This research was supported in part by the Advanced Research Projects Agency under Ft. Huachuca contract number DABT63-91-C-0001, entitled “Gigabit Network Communications Research”.) If the Ph.D. program can be conceived as a Marathon run, Ari Medvinsky was my running partner. We started the program together, ran the full distance together and defended about the same time. We encouraged each other in uphill thrusts, and Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. shared our joy during downhill breathers. Ari was also an actual running partner, and our countless runs along Venice Beach helped me keep in shape, both mentally and physically. My special thanks to Dr. Paul Francis who from our first collaborative research has been a friend, a role model and an inspiration. I am also grateful to Dr. Doug lerardi who inspired my enthusiasm for the more theoretical aspects of computer science. I would like to acknowledge all the members of the USC networking and dis tributed systems laboratory (past and present): Lee Breslau, Jacqueline Chame, Ron Cocchi, Ahmed A.G. Helmy, Steve Hotz, Polly Huang, Sugih Jamin, Shih-Hao Li, Charley Liu, Danny J. Mitzel, Katia Obraczka, Puneet Sharma, Brenda Tim merman, Kannan Varadhan, Liming Wei and Daniel Zappala. This friendly bunch formed a research environment that was both stimulating and a lot of fun! I am very fortunate to have a wonderful family that have always supported and encouraged me. No matter the distance, we were never really apart. I wiU always be grateful to my parents, Rachel and Moshe who have always given me more than I could ever have asked for. My special thanks to my sister Tamar, whose thoughtful, scholarly and helpful advice was always available, when needed. To my sister Idit my thanks for making sure that I walk the land and keep my feet firmly on solid ground. Last, I would like to thank my friends, especially Yuval Levy, frit Yadin-Lempel and Valerie Abijmil for their support, friendship, patience and understanding. Ill Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C ontents A cknow ledgm ents ii List O f Figures v List O f Tables vi A b stract vii 1 In tro d u ctio n and M otivation 1 1.1 Integrated services packet networks (IS P N )............................................ 2 1.2 Multicast challenges ................................................................................. 4 1.3 Research approach and dissertation o u tlin e............................................ 5 1.3.1 Cost allocation and pricing............................................................ 6 1.3.2 Axiomatic approach ...................................................................... 7 1.3.2.1 The basic network model ........................................... 7 1.3.2.2 Axiomatic analysis........................................................ 8 1.3.3 Accounting m echanism s............................................................... 8 1.3.4 Extensions to models and m echanism s...................................... 9 1.3.5 Design and prototype implementation.......................................... 9 2 R elated W ork 11 2.1 Integrated services packet netw orks......................................................... 12 2.1.1 Service model and admission c o n tr o l.......................................... 12 2.1.2 Resource reservation..................................................................... 13 2.1.3 Reservation styles............................................................................ 15 2.2 Multicast distribution m o d e ls.................................................................. 15 2.2.1 Shortest path (SP) multicast p ro to co ls...................................... 16 2.2.2 Shared tree multicast p ro to co ls................................................... 17 2.3 Internet usage metering and accounting.................................................. 18 2.4 Game theory and economics..................................................................... 22 IV Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3 T he Cost A llocation M odel 24 3.1 Basic definitions.......................................................................................... 25 3.1.1 Network technology............................................................................ 25 3.1.2 Incurred c o sts..................................................................................... 26 3.1.3 Allocated c o s ts .................................................................................. 27 3.2 Examples of cost cdlocation strategies......................................................... 28 3.2.1 Equal tree split ( E T S ) ......................................................................28 3.2.2 Equal link split downstream (E L S D )......................................... 28 3.2.3 Equal next-hop split (ENHS) ..................................................... 29 3.2.4 Unicast .............................................................................................. 29 4 A xiom atic A nalysis 31 4.1 Basic axioms ............................................................................................. 32 4.2 The canonical form of cost allocation..................................................... 34 4.3 Examples of cost allocation strategies..................................................... 37 4.4 Additional axioms....................................................................................... 38 4.5 Discussion................................................................................................... 45 5 A ccounting M echanism s 47 5.1 One-pass accounting schemes ......................................................................48 5.2 Model 1 ...................................................................................................... 52 5.2.1 Reduced Basic A xiom s.................................................................. 52 5.2.2 The one-pass Canonical F o r m ..................................................... 53 5.2.3 E x am p le s....................................................................................... 55 5.2.4 Additional A xiom s........................................................................ 56 5.3 Model 2 ...................................................................................................... 59 5.4 D is c u s s io n ............................................................................................. 59 6 Extensions to th e basic netw ork m odel 62 6.1 Multiple quality of service (QoS) le v e ls.................................................. 63 6.2 Multicast distribution m odel..................................................................... 64 6.3 Multiple senders.......................................................................................... 65 6.3.1 Shared channels.............................................................................. 65 6.3.2 The canonical form of shared c h a n n e ls..................................... 67 6.4 Cost allocation over network clo u d s........................................................ 68 6.4.1 Modeling network clouds.............................................................. 69 6.4.2 Cloud incentives ........................................................................... 70 7 Extensions to th e one-pass m echanism 72 7.1 Multiple QoS levels.................................................................................... 73 7.2 Multiple senders.......................................................................................... 73 7.2.1 Mechanistic observations.............................................................. 75 7.2.2 The modified one-pass mechanism............................................... 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7.2.2.1 Pseudo code.................................................................... 76 7.2.2.2 Exam ple.......................................................................... 78 7.2.3 Synchronization............................................................................... 79 7.2.4 Evaluating the size of control m essages...........................................80 7.2.5 Per-source allocation of shared channel c o sts................................. 84 7.2.6 Discussion........................................................................................ 84 8 Design and p rototype im plem entation 86 8.1 Overview........................................................................................................... 87 8.2 The local policy modules (LPM) m odel...................................................... 88 8.2.1 LPM: policy..................................................................................... 89 8.2.2 LPM: local ..................................................................................... 90 8.2.3 LPM: m o d u le .................................................................................. 91 8.3 Sample scenario: simple access c o n tr o l...................................................... 91 8.4 The LPM in terface.................................................................................... 93 8.4.1 POLICY -DATA objects: semantics and format ...........................94 8.4.2 LPM se rv ice s.................................................................................. 95 8.4.2.1 Services Overview......... ................................................... 96 8.4.2.2 Support se rv ic e s............................................................ 97 8.4.2.3 Processing incoming messages......................................... 98 8.4.2.4 Processing outgoing m essages......................................... 99 8.4.2.5 Reservation s t a t u s ......................................................... 99 8.5 RSVP related issues ................................................................................... 100 8.5.1 State m ain ten an ce.......................................................................... 100 8.5.2 Default handling of policy data o b jects.........................................101 8.5.3 New RSVP message: reservation R e p o rt......................................102 8.5.3.1 Security issues ................................................................. 102 8.6 LPM internals................................................................................................ 103 8.6.1 LPM configurations.......................................................................... 103 8.6.2 The LPM layered Design.................................................................103 8.6.3 Interaction between handlers...........................................................104 8.6.4 Default handling of policy data o b jects.........................................105 8.7 Multi Cost: multicast cost allocation...........................................................106 8.7.1 Simple d eb itin g ................................................................................ 106 8.7.2 MultiCost (M C o st).......................................................................... 107 8.7.2.1 Obtaining input information ........................................107 8.7.2.2 Allocating costs to receivers.............................................108 5.7.2.3 Implementation for shared channels................................108 8.8 Implementation experience......................................................................... 109 V I Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 9 S um m ary and Conclusions 110 9.1 Contributions................................................................................................ I l l 9.1.1 Abstract m o d elin g ...........................................................................I ll 9.1.2 Axiomatic a n a ly sis...........................................................................I l l 9.1.3 Simple and scalable mechanisms.....................................................112 9.1.4 Canonical form representation........................................................112 9.1.5 The LPM architecture....................................................................113 9.2 Significance of w ork.......................................................................................114 9.3 Future w o rk .................................................................................................. 114 9.3.1 Unexplored issues..............................................................................114 9.3.2 Detailed design and implementation...............................................115 9.3.3 Additional p o lic ie s...........................................................................116 R eference List 118 V ll Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List Of Figures 3.1 A simple example of a network................................................................ 28 4.1 Merging nodes with no cost link: the Equivalency a x io m ................. 37 4.2 Equal Tree Split transformations: cases A,B,C,D.................................43 5.1 Subset monotonicity vs. one-pass m o d e l............................................. 51 5.2 one-pass, model 1 vs. Equivalency......................................................... 52 5.3 No-Free-Rider axiom in model 1 ............................................................ 57 6.1 Shared channel scenario: audio conferencing with WF reservation style 66 6.2 Shared channel scenario: audio conferencing with WF reservation style 67 6.3 Cloud scenario: setting tunnels across clouds....................................... 69 7.1 Shared channel e x a m p le ....................................................................... 74 8.1 Simple access c o n tro l............................................................................... 92 8.2 The modulax context of access control ...................................................... 94 8.3 POLICYJDATA objects, format, integrity and handling.................... 95 8.4 LPM and RSVP: message flow o u tlin e ................................................ 96 8.5 Disassembly of an incoming Resv message with POLICYJDATA objects 104 8.6 Assembly of POLICY JD ATA objects for an outgoing Resv message . 105 8.7 one-pass, model 2 over L P M ................................................................. 108 V lll Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List Of Tables 7.1 Costs allocated to members following the exam ple....................................75 7.2 Algorithm: Phase I: obtaining subscription inform ation...........................76 7.3 Algorithm: Phase II: allocating costs to subscribers............................. 77 7.4 Messages sent upstream following the exam ple...................................... 79 7.5 Messages sent downstream following the e x a m p le ....................................80 IX Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A bstract The original, time-honored internet architecture had Uttle need for accounting: the infrastructure was supported by substantial government subsidies; the community was cooperative, and service requirements were modest. However, in recent years, with the rapid proliferation and privatization of the Internet, we have witnessed its metamorphosis. Currently, the Internet no longer relies on government subsidies, instead, it is run by service providers who compete aggressively by offering a wide range of affordable connectivity options to the general pubhc. As a result, the tra ditional internet community is rapidly giving way to new, more diverse, and less cooperative user population. It is in the context of this metamorphosis that the need for controlling access and recovering the costs of network resources becomes apparent. Accounting for unicast traffic poses little conceptual difficulties, and can be based on information included in packet headers. However, when we attribute costs to receivers, accounting for multicast becomes significantly more challenging. Multicast is an efficient alternative to having multiple, separate, unicast transmis sions. In this work, we are interested in the way in which these savings are shared among the members of the multicast group Our research is focused on “ ‘Cost Alloca tion”] it is crucial to distinguish between cost allocation and pricing. Cost allocation, describes how the network assigns, internally to itself, portions of the total cost to vaxious users. In contrast, pricing is the form and amount of payment extracted from the end user which is often based on many factors besides costs. We consider the relationship between prices and costs as an orthogonal issue and therefore, we do not investigate it in this work. The current pricing structure in the Internet is based mainly on “flat-rate” strate gies, which usually do not reflect multicast costs. Our work takes a different ap proach: we present a simple and scalable architecture for allocating multicast costs to receivers. We suggest methodologies, accounting strategies, specific mechanisms Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. for implementing these strategies, and a design for a prototype implementation. We start by presenting a basic network model. Our model provides a formal description of the network technology and the structure of incurred costs for multicast trans mission. We analyze the assignment of costs to the receivers of the multicast group, mainly because it is the receivers and not the senders, who determine the multicast distribution, and because attributing costs to sources is simple and straightforward to implement, if one wishes to do so. We analyze the network model through the use of axioms. We use as axioms some possible properties that desirable cost-sharing formula might have. We then investigate the implications of assuming these properties, and eisk ourselves what would be the most desirable strategies for accounting. After we discuss cost allo cation strategies, we turn to discuss candidate mechanisms for implementing them. We are looking for the simplest and most scalable mechanisms that could implement desirable cost allocation strategies. We then present a class of accounting schemes we call one-pass, which complies with our scaling expectations and is shown to be quite simple to describe and implement. The first part of our work is based on a basic network model that is simple, yet powerful enough to describe mainstream networks. For reasons of simplicity, some network technologies are not included in the original basic network model, however, later we discuss extensions to the basic model, that broaden the reach of our work to these additional network technologies. Our work concludes by presenting our design for a prototype implementation; rather than tailoring an implementation for one particular cost allocation scheme, we designed a more general mechanism. Our design attaches a generic, modular “box”, called LPM (for Local Policy Modules), to reservation protocols (e.g., RSVP). The LPM box is capable of supporting a wide range of policies and allows inter operability of multiple cost allocation, accounting, and access control schemes in one generic policy-based admission control mechanism. X I Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 1 Introduction and M otivation The rapid transformation of the Internet, caught many by surprise. A few years back, the Internet mostly provided basic connectivity for military, academic and corporate research engineers. Now, it provides a wide range of services, for a community that more and more resembles the general public. The original design of the Internet, its long history of government subsidies, and the relatively cooperative community it used to support, were some of the contributing factors to the lack of research interest in internet accounting.[12]. With the proliferation and privatization of the Internet infrastructure we expect more network trziffic and applications to cross domain boundaries, use infrastructure of competing network providers, and even select or reject a route based on the identity of an intermediate provider.^ As a result, the internet community is now forced to confront these issues: research in these topics (both academic and commercial) is expanding fast, and in the meantime, commercial hardware, software, and service providers struggle for solutions. Some argue that accounting is not a network architecture issue at all, and therefore, should be left in the service-marketing domain. We would like to stress that in this work we are not interested in pricing per-se, but in cost allocation (for more about the difference between cost allocation and pricing see Section 1.3.1). ^IPv6 uses the extended routing header to support provider selection in a manner similar to the loose source routing option in IPv4. The IPv4 routing option was not widely used due to the high performance penalty involved in any IPv4 option processing. In contrast, no such penalty is expected for IPv6. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. The current pricing structure in the Internet is based mostly on “Flat-rate” approaches.^ In this work, we demonstrate how cost allocation to receivers, that takes into account the nature of multicast, can be achieved through simple and scalable mechanisms. In the remaining sections of the introduction we present some of the specific issues driving the need for internet accounting, and contribute to its complexity. 1.1 Integrated services packet networks (ISP N ) The Internet’s original network architecture, epitomized by the TCP/IP [12] protocol suite, remained virtually unchanged since its original design. This architecture sup ports a single quality of service (QoS), known as “Best Effort”. One of the transfor mation of the Internet manifests itself in the wide range of services it is now required to support (from simple e-mail to virtual reality HDTV). The Internet has evolved to support the emerging Integrated Services Packet Networks technology.[15] ISPN ar chitectures typically incorporate three elements: service model,^ admission control, and resource reservations. Service Model Typically, nodes define the service model, and the range of QoS levels they support. The service model defines a set of services and types of service com mitment [65] (e.g., guaranteed, predictive, controlled-delay, etc.). Services may be sub-divided into distinct levels of quality of service (QoS). Typically, traffic is classified at each hop, by either explicit or implicit rules to. Once a packet is classified, it is scheduled; scheduling involves the reordering of outgoing packets in a way that ensures the service guarantees made to users.[15] •Some examples of “flat-rate” approaches: costs may be based on the speed of the access line (regardless of actual usage). Costs may also be based on network admittance. This means that fixed fees are imposed at the entry point to the network (e.g., per-byte cost for actual transmitted data). Flat-rate approaches do not meter or even estimate the actual impact and overhead of the transmitted traffic: for instance, they do not account for the nature of multicast, and the savings it generates. ^Some advocate implicit ISPN designs which do not depend on for resource reservations or admission control mechanisms; instead, packet or flows are classified locally, according to general characteristics of the data flow, and priorities are set between these classes Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Admission Control In limited-resource environments, service guarantees can be made and kept only as long as the network resources are not over committed. The role of the local admission control is to inspect new service requests, aind consequently, de cide whether local resources are sufficient to satisfy the new requests alongside ail the pre\aously-admitted service commitments. Resource Reservation So far, we have discussed how service models are implemented locally, at indi vidual nodes. However, to achieve end-to-end guarantees, there is a need for a signaling mechanism to com m unicate across multiple nodes along the data path. Reservation protocols like RSVP fulfill that need, and much more: fol lowing the belief that the best knowledge about the required service lies with end users, reservation protocols provide users with the ability to medce explicit service requests. These protocols communicate user requests along the data path, install explicit reservation state, receive confirmation from local admis sion control components, and provide users with feedback about the end-to-end status of their reservations."* ISPN architectures pose challenges and raises several issues of costs and policy enforcement. If users are free to select whatever QoS they desire, why wouldn’t they always choose the highest one available? In a less them fully cooperative community (e.g., the Internet), we expect ISPN networks to be accompemied by mechanisms that provide incentives and enforcement for encouraging reasonable user behavior. It is well established that users tend to conserve resources when their usage is not free. Moreover, from [17, 18, 29, 39, 38] we have learned that given multiple QoS levels, careful pricing can potentially lead to higher levels of individual user satisfaction, as well as overall higher network utilization. Even in fully cooperative environments, usage feedback may éJso prove beneficial; feedback about the overhead imposed on the network by individual cooperative users may assist them in voluntarily adjusting ^The End-to-end status of a reservation can be implicit, in the presence of adequate service and the absence of error messages. It may also be explicit, confirmed by an ack message sent to the originator of the reservation. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. their behavior. We can see network-level accounting is a key element in successful deployment of such Integrated-Services Packet Networks. 1.2 M ulticast challenges Accounting for unicast traffic is rather straightforward; Unicast packets carry both the source and destination addresses, which uniquely identify the path the packet is traversing.® Unicast routes fluctuate quite infrequently, and accounting for them can be considered relatively static. Attributing costs to users is quite simple; there are only two users responsible for the transmission, the sender and the receiver, and the only variable is how to split the cost between them. If we only attribute costs to senders, it is irrelevant whether the distribution is unicast or multicast. However, when we attribute costs to receivers,® accounting for multicast distributions becomes significantly more challenging, both conceptually and mechanistically. The concep tual challenge is deciding how to share the saving of the multicast distribution among the receivers. The is no single obvious answer for this challenge, and the discussion often involves normative issues like fairness and equality, rather than technical ones. There are Mechanistic challenges as well: multicast addresses represent logical group membership. While the source and destination address pair provides forwarding in formation, it merely identifies the next hops of the multicast tree, but does not reveal the full topology of the multicast distribution.^ Multicast distributions tend to be quite dynamic; group membership, especially in large groups, changes often, causing changes in the multicast distribution. Accounting mechanisms for multicast must be able to adapt to these changes. Another important challenge originates from the main motivation for multicast, which is efficiency. As an alternative to having multiple unicast transmissions, multicast conserves network resources by forwarding ®If addresses encode topological (geographic or provider based) information, the overall cost of the path can be computed at the edge of the network. (See [24]). ® Attributing costs to the sender is straightforward and simple, however, in our work we concen trate on attributing costs to receivers, mainly because they are the ones that determine the shape of the multicast tree, and because it is a challenging problem in need of solution. ^Some exceptions to that general rule are possible. It is possible for a conference to target a pre-determined set of receivers, or to limit its scope to a well known distribution (e.g., multicast scope (TTL) supported by DVMRP). However, these should be considered the exceptions, and not the general rule. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. only a single copy of each packet on any link. The way by which these savings are shared among the members of the multicast group is not trivial: the challenge is to split the costs of the multicast tree between the group members in a m anner that is equal, fair, and provides incentives for users to prefer multicast over unicast. The last challenge is mechanistic; IP multicast routing is highly scalable, since the over head over any interface is fixed with respect to the size of the multicast group (in terms of both number of receivers, and geographic dispersity). Accounting mecha nisms for multicast should have similar scaling properties; in other words we search for mechanisms that are capable of splitting costs between a dynamically changing set of group members, over a dynamically changing distribution, in an equal and fair manner, yet, these mechanisms should have similar scaling properties to multicast. 1.3 Research approach and dissertation outline The commercialization and privatization of the Internet, which occurred only in recent years, is considered among the triggering factors for the increased interest and research work in this area. The research agenda is still being shaped [60], and while several directions have been suggested (see Section 2.3) there are few (if any) general models and methodologies that have reached a consensus, or were accepted by the computer networking community.® At this early stage of the research, a possible approach could be to design an ad-hoc mechanism that would provide some reasonable solution.® However, while being a valid approach, ad-hoc solutions usu ally do not contribute to the general understanding of the problem; they do not lay ground rules, define models or propose methodologies for future research evolution. Perhaps most importantly, without models of methodologies, it is hard to compare their properties with other mechanisms. The set of properties satisfied by an ac counting scheme is quite crucial and has a substantial impact on its acceptance and successful deployment: accounting schemes that are arbitrary, unfair, or discrimina tory, may be rejected even when they are based on highly efficient mechanisms. On ®Pricing and cost allocation methodologies are well established in economic research, but, those methodologies aren’t trivially applied to computer networks. Computer networks pose new prob lems, (e.g., multicast protocols), and impose additional restrictions, originating from mechanistic constraints and scalability factors. ®An example for what we consider an ad-hoc solution can be found in [25]. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the other hand, accounting mechanisms may become overly complex due to a desire to make them as general and as powerful as possible. In this work we suggest methodologies, define models for internet accounting strategies, suggest specific mechanisms for implementing these strategies, and present a design for a prototype implementation. We divide our work into three main com ponents that roughly corresponds to the following questions: (1) Assuming we had no mechajiistic constraints of any sort, how would we define a reasonable set of pre ferred accounting strategies? (2) What is the simplest mechanisms that can satisfy this set of accounting schemes (3) What is required (in terms of network technology and model extensions) in order to design and implement these mechanisms? The following sections describe our approach to each of these questions. 1.3.1 C ost allocation and pricing We are interested in accounting for network “costs”. Cost feedback is important for promoting the efficient use of network resources, whether we are in competitive or co operative environments. In competitive environments, usage tends to be influenced by cost incentives, and in cooperative environments, users wishing to voluntarily adjust their behavior may need to first know the impact that their usage imposes on the network. It is important to note the these costs can be represented in terms of congestion-induced performance degradation imposed on other users and/or in terms of the actual capital and maintenance cost of the network facilities themselves. In this work we do not address the question of how network costs are set, instead, we assume they axe pre-set, and deal with the questions of attributing them to users. It is crucial to distinguish between cost allocation and pricing. Pricing is the form and amount of payment extracted from the end user; pricing schemes axe often based on many factors besides cost, such as demand elasticity, market structure, and price stability. Cost allocation describes how the network assigns, internally to itself, portions of the total cost to vaxious users. There is not necessaxily any direct relationship between the allocated cost and the prices charged individual users. In fact, we expect that in most cases, allocated costs, even if they axe monetary, will not be turned directly into prices. However, even though not charged directly, these allocated costs can serve as useful input to some pricing schemes. For instance. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. network users might buy a monthly quota of network service, and the amount that was debited from this quota would be based on the allocated costs. The user would have the benefit of extreme price stability (in terms of what they paid every month) but yet would also gain from the increased efficiency of multicast.^® 1.3.2 A xiom atic approach Our work is based on using axiomatic analysis as a methodology for exploring ac counting strategies. Here, we ignore all mechanistic constraints, and ask ourselves what are the desired strategies for accounting. 1.3.2.1 T he basic netw ork m odel If we are to explore the different cost allocation strategies, in a non-mechanistic con text, we must be able to model these strategies within an abstract network model. Such a model must be powerful enough to provide accurate modeling of the multi cast networking environment, yet, it must also be simple enough to provide a basis for analysis. In Chapter 3 we present such a model; the basic network model pro vides a formal description of the network technology for multicast transmission over a network. It also defines the structure of incurred costs across the network. The network technology in our basic model, follows the classic, main stream concept of multicast as presented in [21]: given a single source and multiple receivers, multicast transmission is carried over a source-rooted tree, computed as a union of all unicast routes between the sender and each of the receivers. The model assumes the multi cast tree is static (for some S time) and that all the receivers axe provided with the same quality of service (QoS). The model’s cost structure associates incurred costs with links. We axe making the fundamental assumption that costs axe assigned to the re ceivers of the multicast group, and not to the sources, for two reasons: first, it is trivial to assign a fixed portion of the costs to the source, and this changes almost should also point out that even though costs are allocated to individual users, the recovery of those costs might occur at a much higher level of granularity. For instance, USC might be responsible for all of the costs allocated to its students and staff. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. nothing in our analysis except to complicate notation. Second, multicast member ship is typically receiver initiated (see [21]), and so, the responsibility for data flowing over links rests primarily with the receivers. 1.3.2.2 A xiom atic analysis In Chapter 4 we evaluate different cost allocation strategies. We analyze the network abstract model through the use of axioms. We use as axioms some possible properties that desirable cost-sharing formula might have. We then investigate the implications of assuming these properties. What additional properties are implied? What forms of cost-sharing rules are allowed? First, in Section 4.1, we identify three basic axioms that describe the process of allocating cost. These axioms describe which aspects of the problem are relevant to the cost-sharing formula. We assume that the basic axioms apply throughout the rest of Chapter 4. We then discuss the implications of these basic axioms, and present a few examples of cost allocation policies that satisfy them. Last, We identify a few additional axioms that express different policy objectives of cost-sharing, and explore the implications of each of these axioms when combined with the three basic axioms. At the end of Chapter 4 we discuss the results of applying axiomatic analysis over the basic network model. This analysis provides us with information about the properties held by the different cost-allocation schemes; it also allows us to identify the set of acceptable cost allocation schemes, and suggest the most attractive ones. 1.3.3 A ccounting m echanism s After we discuss cost allocation strategies, we turn, in Chapter 5 to discuss candidate mechanisms for implementing them. Clearly, we are looking for the simplest and most scalable mechanisms that would be powerful enough to implement those cost allocation strategies that we found to be most attractive. It is important that the traffic load imposed by the accounting mechanism on any particular link should not increase (without bound) with the size (in terms of numbers or in geographical dispersion) of the multicast group. We present a class of accounting schemes we call one-pass schemes, which complies with our scaling expectations and which is shown to be quite simple to describe and implement. We discuss two models of 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. implementation of such schemes, models 1 and 2, which differ in the information provided about downstream members. Each of these models is examined according to the centrai question raised throughout this section: what forms of cost allocation schemes can this family of accounting mechanisms support? 1.3.4 E xtensions to m odels and m echanism s The first part of our work was based on the basic network model which was simple, yet powerful enough to describe mainstream networks. For reasons of simplicity, some network technologies were not included in the original basic network model. However, in Chapter 6 we discuss extensions to the basic model, which broaden the reach of our work to these additional network technologies. We discuss extending the model to allow multiple qualities of service, additional multicast protocols, multiple senders, and accounting over network clouds. We continue, in Chapter, 7 to discuss the impact of these extensions over the cost allocation mechanisms we propose. Some of these extensions have nearly trivial effects, but others have profound impact on the basic mechanism. 1.3.5 D esign and prototype im plem entation The design of a prototype implementation completes the cycle of our work. After we discuss the theoretical aspects of cost allocation and some possible mechanisms to implement them, we shift our focus in Chapter 8 to present our design for a prototype implementation. In our design, we discuss some of the issues involved in applying the generic mechanism to resource reservation protocols. A possible simple approach could have been to design a specific implementation, tailored for one particular cost allocation scheme. However, we decided in favor of a more general mechanism, one that would maintain the flexibility needed for the evolution of research in this area. It is important to note that while we detail a design for an RSVP prototype implementation, we believe that this architecture applies, in general, to other similar reservation protocols. Our design attaches a generic, modular “box”, called LPM (for Local PoUcy Modules), to reservation protocols (e.g., RSVP). The LPM box is capable of supporting a wide range of policies, and allows inter-operability of multiple cost allocation, accounting and access control schemes in one generic policy-based Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. admission control mechanism. In Chapter 8 we describe the building blocks of the LPM architecture, and the way in which these building blocks can be conhgured to implement various cost allocation schemes. 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 2 R elated Work In recent years, we have seen a dramatic shift, and rapid growth in the interest and literature on pricing and accounting in computer networks. However, the amount of research work in this area falls short in comparison with more traditional mainstream networking areas. This trend is even more evident when multicast is introduced to the problem. In this chapter, we present the technical areas related to our work. We start in Section 2.1 with the network infrastructure itself, describing the Integrated Services Packet Networks (ISPN) architecture. We then continue, in Section 2.2, to discuss multicast distribution models. In Section 2.3 we describe both historical and current work exploring various internet accounting issues. We conclude, in Section 2.4, with some related work in economics, and more specifically, in the game theory discipline. 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.1 Integrated services packet networks Integrated Services Packet Networks (ISPN) evolved to support the wide variety of service requirements imposed by computer applications (ranging from simple email, to HDTV). Eaxly work on integrated services originated from circuit switching net works (e.g., ISDN systems [11]). Real time integrated services over packet networks was explored by the experimental ST [28] and ST-II [66] protocols. Experience with these systems promoted the exploration of integrated services for IP networks. Early work on an ISPN architecture for IP networks was presented by Clark et ai. [15]. Zhang et al. [74] provide a slightly higher level view which incorporates resource reservations as a key component of the ISPN architecture. For the purpose of our discussion, we identify three key components in ISPN architectures:^ service model, admission control, and resource reservation.^ We now discuss each of these key components. 2.1.1 Service m odel and adm ission control The service model describes the range of network services provided by ISPN archi tectures. To meet its service commitments an ISPN must ensure that its scarce resources are not overcommitted. Typically, an admission control component in spects new service requests; it decides whether they should be admitted or rejected based on the availability of local network resources. Service models describe desirable service commitments (as opposed to the algorithms for achieving them). However, these commitments are typically supported by specific scheduling models, which de termine the internal allocation of network resources [61]. Numerous service models ^Currently, the work carried by the IETF is divided into two VVG: RSVP, discussing resource reservation issues; and IntServ, discussing the service model. Admission control seems to be outside the scope of these two working groups. The introduction of policy based admission control, led us to believe that admission control (based on resources or policy) should be considered a separate piece of the architecture. ^We did not include routing and flow specifications in the key components; the current ISPN design advocates obtaining routing information from existing routing protocols. Therefore, routing should not be considered a component of ISPN, but instead, a service of the network used by ISPNs. The same logic applies to flow specification: ISPN architectures use whatever flow specification is provided by the underlying network architecture (i.e., by examining the packet header fields). 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. were proposed in the literature. Here we discuss several of the more notable exam ples. Traditional reaJ-time service provides absolute bounds on the delay of each individual packet. In the literature, this model is known as guaranteed service [15]. As the néime suggests, guaranteed service was designed to maintain service com mitments, under worst case traffic sceneirios.^ The absolute nature of guaranteed service precludes admission control from taking advantage of statistical multiplexing between flows, and as a result, imposes low utilization of network resources. There are several other service models and admission control approaches that attempt to achieve higher utilization by weakening the level of commitment éissociated with the service model. For instance, the probabilistic service described in [73] provides a probability of lost or late packets, by taking advantage of statistical multiplexing. In this approach, each flow is assigned an effective bandwidth larger than its av erage rate but less than its peek rate. Jamin et al. [36, 35] critique this model, expressing their opinion that it is difficult, if not impossible, to provide accurate and tight statistical models for each individual flow. They offer a different model called predictive service, which uses measurement based admission control. This approach uses a priori source characterization for new flows, but performs actual traffic mea surements to discover the aggregate load of previously admitted (old) flows. Current work on service models for internet ISPNs is being carried out by the IETF (Internet Engineering Task Force), IntServ Working Group. The group produced documents describing a genereil template for defining new services [65], and specific service mod els: guaranteed [63], committed [4], predictive [62] and controlled-load [71]. We are currently unaware of any particular work offering viable admission control solutions for these service models. 2.1.2 R esource reservation The third component of an ISPN architecture is resource reservation. In order to keep its service commitments to users, an ISPN usually set aaide specific resources, such as a portion of the available bandwidth, buffer space, processing speed, or any ^Obviously, no resource reservation can protect against physical network failures, when equip ment fails. 13 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. other resources needed to service the specific user/flow. To achieve end-to-end ser vice, there is a need for a signaling mechanism that communicates service requests to nodes along the data path, reserve and release local resources, evaluate end-to-end service commitments and communicate them to end-users. Such signaling mech anisms are usually referred to as “reservation protocols”. Traditionally, resource reservations have been associated with circuit switching networks, like the telephone systems[ll]. One of the early resource reservation protocols for packet networks was ST [28] and its successor ST-II [66]. In ST-II, reservation setup is initiated by the source: the source sends a connect message to all the initial receivers, and waits for a reply from each of them. Group membership dynamics is handled by the source; the source includes additional new receivers by issuing a new connect message. It can also release existing receivers through a disconnect message. An ST-II reserva tion is confirmed only with each specific receiver reply. Other resource reservation protocols were proposed by Anderson et al. [1] and Ferrari [27]. A novel approach to resource reservations, RSVP (ReSerVation Protocol), was introduced by Zhang et al. [74, 8]. RSVP is a setup protocol for installing reservation state along the data distribution path. (For detailed comparison of RSVP and ST-II, see [44].) Its design principles are described in [74]: (1) receiver initiated reservations (2) separation of reservations from packet filtering (3) different reservations styles (4) “soft-state” (5) protocol overhead control, and (6) modularity. Having receivers initiate reservations allows some level of heterogeneity among receivers (e.g., in their QoS requests). RSVP uses two basic control messages:'* Path and Resv messages. Path messages, are sent from senders to receivers, following the data multicast distribution tree. Resv message axe sent from receivers to senders, reversing the path that was set by Path messages. These messages are delivered on a hop-by-hop basis; at each hop they traverse, they install Path or Resv state respectively. RSVP uses a soft-state mechanism to install this state.® Soft-state mechanisms have the advantage of being '‘Other control messages, ResvErr, PathErr, TearDown, etc., are part of the RSVP functional specifications, however, they are required for real world deployment, rather than by the basic concept of RSVP. ®The concept of soft-state was first proposed in [12]. Soft state describes the family of mecha nisms that are hybrids between hard-state and stateless protocols: on one hand, state is installed in routers, and is needed for correct operation of the protocol. On the other hand, the loss of state in an intermediate router does not require a new end-to-end setup negotiations, instead, the lost state is repaired loccJly. Soft-state mechanisms typically rely on periodic and event driven hop-by-hop 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. able to locally and quickly adapt to topology or group membership changes, without the need for a new end-to-end setup negotiations. The RSVP protocol overhead is controlled through receiver state merging: at each node, the reservation state from ail downstream branches is merged, and only a single upstream reservation request, representing all downstream requests, is sent. 2.1.3 R eservation styles One of the strong features of RSVP is its reservation styles support. Reservation styles allow RSVP to take advantage of application or human characteristics to ag gregate reservation requests, conserve reserved resources, and therefore, have better scaling properties. The current RSVP design [ 8] describes reservation styles through a set of aggregation options: (1) a reservation can be distinct, or shared by meiny senders, and (2) a reservation may be shared by an explicit list of senders, or by all senders (also known as wildcard sender). A frequently used example for Wildcard Filter (WF)® audio conferencing is described in [74]: human conventions suggest that no more than a single person may speaks at any given time. Hence, there is no need to reserve for more than one sender, on any given link, regardless of the actual number of participants. Other reservation styles that have been proposed are Dynamic Filter (DF)^ and Shared Explicit (SE). In our work we discuss the model of shared channels, which are reservations that have the shared reservation flag set in their STYLE object (i.e., DF and SE). Sharing a reservation among multiple senders, adds another dimension to our work (see the discussion in 6.3.1). 2.2 M ulticast distribution m odels Multicast routing is a highly efficient technology for multipoint transmission. Using unicast for multipoint delivery would require the sender to send a separate packet refreshes. State refreshes must include enough information to allow a receiving router to perform setup on the fly, based solely on an state included in the individual refresh message. ®WF is represented in the STYLE object using the Shared reservations and Wildcard flags. ^DF reservation style was dropped out of the rsvp-spec [8], at least temporarily, due to technical complexities. 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to each of the receivers (resulting in multiple identical copies transmitted over the same link). Multicast routing is significantly more efficient; it guarantees that the same packet will never traverse any link more than once. Multicast is conceptually divided into two parts: routing and forwarding; multicast routing protocols define the multicast distribution (tree) and install the appropriate forwarding state in indi vidual nodes. Multicast forwarding consists of a look-up in the forwarding table, and forwarding the multicast packets accordingly. Even if multicast routing is performed individually by each routing protocol, actual packet forwarding can conceptually be shared by several, compatible, routing protocols. In this section we describe the current multicast technology; we discuss protocols that are édready deployed over the Internet as well as promising, newer protocols. 2.2.1 Shortest path (S P ) m ulticast protocols There are several multicast routing protocols that form shortest path (SP) multicast trees. These trees can be thought of conceptually as a union of the unicast, shortest paths, from the sender to each of the receivers. Deering [21, 20] proposed multicast extensions to both distance-vector and link-state unicast routing algorithms. In his work, Deering introduced some of the basic concepts of multicast: host group and receiver initiated joins. A host group, (more commonly known as a multicast group), represents the set of hosts with receivers of the multicast transmission. This set of hosts is identified by the logical multicast address (the destination address placed in the packet header). With receiver initiated joins, hosts are added to the host group through explicit requests made by receivers, and not by senders. Deering’s work evolved into the Distance-Vector Multicast Routing (DVMRP) protocol,[67] which is currently the most widely deployed multicast protocol. (See [19] for host interface/ extensions for DVMRP.) Despite being wide spread, current DVMRP deployment falls short of providing complete multicast coverage over the Internet. Those parts of the internet that axe not multicast capable are known as “clouds”. Tunnels axe hand configured virtual links that connect two multicast ca pable routers across a cloud. By using such tunnels, DVMRP was able to cover substantial paxts of the Internet, creating what is known as the “MBONE” (Multi cast backBONE). 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. MOSPF [50] (Multicast Open Shortest Path First) is a multicast link-state rout ing protocol, defined as an extension to the OSPF unicast routing protocol [51]. Link- state algorithms, by definition, rely on complete knowledge of the network topology, which makes them less attractive candidates for inter-domain use. MOSPF’s lack of inter-domain success can be attributed in part to these scaling problems. PIM (Protocol Independent Multicast) [23, 26, 22] utilizes both SP and shared trees. SP trees axe always used in PIM’s dense mode. However, in sparse mode the move from the shared tree into source specific SPTs is triggered by the volume of traffic sent by specific sources. PIM is described in greater details in Section 2.2.2. 2.2.2 Shared tree m ulticast protocols There is overhead associated with maintaining SP trees: first, SP trees are source- rooted, and therefore, the number of trees (and the size of state in the routing tables) grows linearly with the number of senders. Second, the dynamic discovery of group membership generates considerable overhead, since it usually includes flooding and pruning. This overhead may is reasonable for dense groups, however, for sparse groups,® if the data rate is low, the ratio of overhead to data becomes quite high, and may be considered unacceptable. The multicast overhead can be reduced if a single tree was shared by all senders. Two new routing protocols, CBT and PIM, utilize this concept of shared trees. The Core Based Trees (CBT) [6, 5, 7] protocol uses a simple shared tree topology. The root of the tree is an arbitrary router, chosen to be the “core”. The CBT shared tree is constructed as an SP tree between the core root and all the members of the multicast group. To send data over a CBT tree, each sender sends its data directly to the core (in unicast delivery), and the core router forwards it along the shared core-rooted multicast tree. The CBT protocol reduces the overhead or sparse groups, however, the penalty is longer routes and higher delays. Protocol Independent Multicast (PIM) [22, 23, 26] uses a sparse mode (SM) to bridge this gap by allowing both shortest-path and shared tree multicast distribu tions to coexist. In PIM, shared trees axe built around one or more Rendezvous ®Sparse groups are characterized by receivers being few and far apart. 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Points (RP) routers.® Receivers join the shared tree by sending an IGMP join to their local designated router (DR). Upon receiving the join request, the DR node sends a join message to the RP node associated with the specific group. As the join message propagates toward the RP node, it installs shared forwarding state (i.e., (*,G)) in intermediate routers, and as a result, establish an RP rooted shared tree. Senders must register before they begin sending over the shared tree, however, to minimize delay, they may send data encapsulated in the join message itself, for on the fly route setup. The resulting tree is made of two parts: a unicast route from the source to the RP and a shared tree from the RP to the members of the multicast group. PIM allows both SP and shared trees to intermix; while shared tree distri bution is the default configuration of PIM-SM, sources may be switched to use SP trees automatically, based on their high volume of traffic. For detailed comparison between different multicast distributions see [69, 70] 2.3 Internet usage m etering and accounting There is a rapidly growing literature on pricing and accounting for computer net works in general. A great portion of this work is in pre-print or technical report form, mainly because this surge of interest in this area is so relatively new. How ever, most of this literature does not typically relate the prices charged to the costs of network usage. The emphasis there is on the strategic behavior of the user, and on the personal and system optimization (in terms of maximal utility) it encourages. Only the very recent body of work [30, 34, 57, 58] attempts to explore the equitable distribution of the network costs among its users. If our goal is to achieve maximal efficiency through network pricing, we must be able to relate the service (in term of what happens to packets belonging to the user) and the specific user utility. A common approach is to define a utility function that takes bandwidth and delay parameters as input and returns a utility value. A good example for this approach can be found in [58]; there it is assumed that individual users behave in the way that increases their individual utility (a.k.a ® Rendezvous Points are similar in concept to the CBT core, in a sense that users join the shared tree through them. 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. greed). The paper discussed the relationship between individual and common utility in various gateway service disciplines (also, see [17, 18, 16, 59]). Unfortunately, computer network tend to behave in a more complex maimer than these theoretical models; applications seem to have a rather complex function of real utility that can be very application specific and could span almost arbitrary sequences of packets. Moreover, utility functions may depend on a combination of multiple applications, (i.e., synchronized audio and video) etc., in a way that makes it cdmost impossible for the network to figure out on its own.^° (See [13] for more details). The recent surge of interest in internet accounting produced many new propos als, some for best-effort traffic, and others for reserved traffic. One of the earlier research questions was about the role of pricing in computer networks. From [17, 18, 29, 39, 38] we have learned that compared to unrestricted free access careful pricing of network services increases the individual user utility, as well as the overall network efficiency. An interesting pricing proposal by MacKie-Mason and Varian [40] advocates a “smart-market” approach; In this proposal, individual packets carry a “bid” in their header, and this bid is used to request service at each router along the path. Each router sets a threshold “cost” and the rule is that only packets with bids that exceed the threshold are served. All serviced packets are charged the same amount, identical to the threshold cost, regardless of their individual bid. The proposal argues that since the bid does not influenced the final cost, and only deter mines whether the packet is serviced, users are encouraged to declare the true value they place on servicing their packets. This proposal exemplifies the benefits of using economic theories for analyzing networks. However, computer networks have several complexities that are not taken into account, and therefore, prevent such a system from reaching true optimality: first, this proposal deals with a single switch case; it is not clear how a user bid for end-to-end service should be broken into per-switch bid. Second, the bid is on a per-packet service, and most applications care about the service for a sequence of packets, and third, loosing a bid for a packet causes considerable delay, a fact that may skew the user bid away from the optimal point. ^°The TCP/IP protocol suite and many other protocols have an architecture that separates the different functional layers of network operations, and disallows lower levels (e.g., network) to have detailed understanding of the applications running on top of it. This prevents the network from knowing the complex relationship between network behavior and user utility. 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Another approach for reaching optimal pricing was proposed by Wang et al. [68]. This proposal targets time-varying demand ATM networks and proposes a scheme for pricing that is based on the demand elasticity and the opportunity costs. A completely different ad-hoc approach could explore possible mechanisms for cost recovery, bypassing issues of pricing or optimality. An example for such an ad-hoc accounting mechanism for TCP, was proposed by Edell et al. in [25]. The proposal advocates intercepting TCP connection establishment messages, and delay ing them until an external protocol verifies the user identity and his/her willingness to pay. This mechanism is fully transparent to applications since all the accounting is achieved through an external protocol. Brownlee et al. in [43, 10] propose a protocol for real time traflSc flow measure ment (RTFM).^^ This protocol is based on several components: (1) m e te r which resides in a router, and measures local traffic. (2) M eter reader which reads meter records, aggregates them and reports them. (3) M anager which control both the meter and the meter reader, and (4) applications. The RTFM Components interact though SNMP, sending MIB records with measurement statistics. Typically, appli cations would identify the specific flows that interest them to the managers. The managers would then activate meters and meter readers and send data responses back to the requesting applications. This approach provides local information about traffic measurements, however, it does not provide enforcement nor does it provide mechanisms for attributing costs to receivers or other network entities. A proposal by Braun et al. in [9] complements the RTFM approach. It assumes some local measurement mechanism (e.g., RTFM) provides usage information, and describes a framework for distributing this information globally. This proposal advocates a decentralized accounting scheme that is performed at Administrative Domain (AD) routers. Each AD router computes the charges for a flow, based on statistical traffic measurements and charges (bills) received from neighboring ADs. If the flow belongs to a local user, that user is charged. If not, the charge is sent, as an aggregated bill, to the next AD along the flow’s path. This proposal has several problems: first, in general, backbone routers maintain aggregated state (subnets, nets etc.,), and ^^This work is being developed by the RTFM WG at the IETF. It was originally proposed as a solution for internet accounting (in two sepeirate BOFs, ACC emd ACC2) however, the IETF created a more modest role for it, within the RTFM WG. 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. not per-flow state. Second, since it is based on implicit, packet header informa tion, accounting would not be done at application/user resolution. Hence, it would not be able to support the notion of logical (as opposed to physical) user identity. Third, and perhaps most important, these proposals approach the problem of uni cast accounting which is significantly simpler than multicast, both conceptUcdly and mechanistically.^^ These multicast challenges were first explored in [34] which was the basis for Chapters 3,4 and 5 of this dissertation. Some of the more technical mechanistic aspects of the relationship between accounting and reservation protocols have been further explored in [31, 32]. At present, the internet community is still debating and shaping the research agenda. Shenker et al. in [60] provide an extensive investigation of research goals and agenda. This paper offers a critique of the optimality paradigm and suggests a new pricing paradigm named “Edge Pricing”. Edge Pricing suggests that the price of a network service can be estimated at the edge of the network (i.e., at the closest point of contact), based on locally available information. Edge Pricing advocates using two basic approximations: the first, “ QoS-sensitive time-of-day” approximates the expected congestion conditions along the path. The second, approximated the expected path. Because these approximations are done at the edge, and are not based on measurements, they do not respond to instantaneous changes in either the congestion or and the traversed path. The paper suggests that this is not a significant drawback, and perhaps can be considered an advantage, since it provides users with stability and ability to make longer term adjustments.^^ One of the toughest issues for Edge Pricing is raised when costs are attributed to the receivers of the multicast distribution. While is straightforward to estimate a unicast path, evaluating a multicast path is quite tricky: first, multicast addresses do not reveal the shape of the distribution or provide the list of the group members. Second, multicast membership and multicast distributions tend to be highly dynamic, even ^^See the introduction (Section 1.2) for the discussion about the challenges of multicast distri butions. The conceptual challenge involves issues of cost sharing among receivers, presented by multicast group membership. The mechanistic challenge, originates from multicast related scaling issues. ^^This is a similar model to the one used for telephony pricing, where the time of day, and the destination address determine the cost of the call. QoS sensitivity is irrelevant for telephone networks, since they only have a single QoS for each equipment type, (e.g., 4KHz voice, ISDN, etc.). 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. within the lifetime of a short conference. Third, the margin of error for estimating multicast cost-shares can be quite large. While unicast costs are bound between the minimum aad maximum costs for a particular path, multicast costs depend on group membership, where the number of receivers can vary by several orders of magnitude. It is therefore reasonable to assume that pure Edge Pricing would need to be accompanied by mechanisms for discovering the ]path, costs, and group membership of the multicast distribution. Shenker et al. [60] refer to our work [34] as a possible solution to these multicast challenges. Another agenda shaping discussion is presented by D. Clark, in [14]; the docu ment provides a high level description of schemes for adding user controlled service discrimination to the Internet. 2.4 Gam e theory and econom ics Cost allocation is discussed in a large number of economics literature. A brief overview and a list of references can be found in [53]. Cost allocation is considered to be a special case of the cooperative game. The cooperative game was originally developed by Lloyd S. Shapley [55, 56]. In cooperative games, a single game strategy is chosen for all N players,^"* and a value function V is defined to associate a value V{S) with each subset of players S. The question investigated in cooperative games is how to assign each player a share, such that the sum of all shares assigned to play ers is equal to the value of the complete set S, or = 1^(5). (see [54, 52]). Cooperative game theory suggests two possible ways for which reasonable cost allo cations may be defined: the first is the axiomatic approach. The second approach evaluates whether a specific cost allocation solution provides immunity from dis ruption by coalitions of players. In our work we have used both of these possible ways.^® When one uses axiomatic analysis, the results often show that a given set of axioms uniquely determines one value vector for each game. In this work, we used axioms that are very similar to those used in the literature and in the theory of ^^This is different from the non-cooperative games, where each player is allowed to independently choose a strategy. ^^Unfortunately, the second approach was proven to lead to a dead end: Theorems 5 and 9 prove that for our network model there exists no cost allocation strategy that can prevent such collusion. 22 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. cooperative g a m e s .T h e re is a very extensive literature on cost allocation in the context of minimal cost spanning tree (m.c.s.t) games. For instance, Sharkey [57] provides éin overview of such games and a broad discussion of network models in economics. However, the m.c.s.t problem differs from the problem presented in this work, since its routing criteria is very different from the one used by most if not all network multicast protocols. In a more recent paper, Henriet and Moulin [30] con sidered a network model where costs are incurred for connecting to a central switch, and the pairwise traffic matrix is known; the spirit of the analysis is very similar to ours, but the network model is rather different. Cooperative games are studied in the context of complete information, assuming that there is a central planner that has access to all relevant information [57], obvi ously, this is not the case for large and scalable network architectures. Our work is geared toward the networking research community, and therefore does not end with the theoretical analysis of the cost allocation problem; we continue by suggesting mechanisms for implementing such cost allocation strategies under realistic network ing constraints, in a simple and efficient manner. While there is large literature on network cost allocation problems, we are not aware of a discussion of the mechanisms needed to implement such cost allocation schemes. ^®Megiddo [41] considered a family of cooperative games which have a structure similar to the problem we consider here. 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 3 The Cost A llocation M odel In this chapter we present the basic network model, which provides an abstraction of the cost-sharing problem. This model defines a formal description of the pertinent network fabric, and serves as the foundation for analysis and description of cost allocation mechanisms. We conclude this chapter by applying the basic model to a few examples of cost allocation strategies. 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.1 B asic definitions In this section, we introduce an abstract model of the cost-sharing problem, which is the basis for our axiomatic analysis of cost allocation. The abstract model provides a formal description of the netw ork technology and the structure of incurred costs for multicast transmission over a network (illustrated in Figure 3.1). 3.1.1 N etw ork technology The netw ork technology model has three components: network topology, group membership, and routing function. Network topology: The network topology describes the physical connectivity of the network in terms of vertices (nodes) and links. N = {V ,L,T) describes a network N, with nodes u; G V, directed}- links (u,-, vj) 6 L and a routing function (protocol) T. M ulticast group m em bership: Let M describe the set of m ulticast group m em bers; we denote individual members by uIq G M. Members of a multicast group can join and leave dynamically and can attach themselves to any node. Each packet sent to this multicast group by any source, not necessarily a member of the group, will go to all members of the group (receivers).^ The mapping of individual members to specific network nodes is described by the location function loc : M \-^V. R outing function: The routing function abstraction describes the path taken by packets when a sender transmits to the group. In unicast routing, the routing function U = T{N, R, V {) takes a network N along with a source (root) R and a receiver Vi and defines the set of directed links that establish the path between R and Vi- While we make no particular assumptions about the optimality of this ^Notice that links are directed and therefore (vi,Vj) ^ (vj,Vi) for all nontrivial links (i.e., V i ^Vj). "Throughout our work, we will use the terms member and receiver interchangeably with no specific distinction. 25 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. unicast route, we do assume that the set of uniccist routes from a single root to all other nodes forms a tree.^ In this work we assume that multicast routing is based on loop-free unicast routing; that is, multicast routing creates a source-rooted distribution tree created from the union of the unicast paths between the root and the set of receivers: T{N, R, V') = T{N, uy) for aU subsets V Ç V. Each link in a distribution tree creates a distinction, relative to itself, between upstream and downstream portions of the tree: the downstream portion contains aU the nodes (and members) that incorporate this link in their unicast path from the root. The upstream portion is merely defined as the portion of the tree that is not downstream. 3.1.2 Incurred costs We now turn to the structure of incurred costs. Our abstract model considers the allocation of costs for each data flow individually (i.e., we do not consider the joint allocation of the costs of multiple flows), where data flow refers to a particular source sending to a particular multicast group destination. Such a flow can be explicit (created by resource reservation) or implicit.'* For reasons of simplicity, we associate all costs with the links that packets traverse.® These costs could arise from many different aspects of network usage; for instance there could be costs associated with each packet and/or costs associ ated with resource reservations (bandwidth, etc.). We lump ail of these different ^This assumption follows if whenever the route from R to node u ,- passes through node Vj, the route from R to Vj is a subset of the route from R to u,-. We also are assuming that routing is only a function of the location of the receiver. Some routing protocols allow receivers to request different quality of service (QoS) routes, which would have violate our assumption had our model allowed more than one QoS. (See Section 6.1 for the discussion of multiple QoS.) '‘Data packets can be classified implicitly into flows by examining their source/destination ad dresses and other significant fields in their headers ® Although most reservation protocols put emphasis on link (as opposed to intra-node) resources, we acknowledge that some intra-node resources may be costly (like internal buffers, CPU cycles, etc.). Intra-node costs can be attributed to links by attributing the intra-node cost associated with processing incoming data to the incoming link and the cost for outgoing data to the appropriate outgoing links. 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. costs into a single quantity.® Because we assume that the same quality of service is delivered to all receivers, link costs are independent of which receivers, or how many, are downstream. Later, in Section 6.1, we discuss generalizations of the model to incorporate multiple qualities of service. Moreover, we should note that our abstract model is intended to address the problem of cost allocation among a given set of group members with a given network topology; our work does not address dynamics, either in membership or in topology.” The set of link costs for a given network N = {V, L, T) is defined as c: L %+. The cost function of a distribution tree comprised of links L' is merely the sum of all the directed links in L': cf{L',c) = Yl{vi,vj)eL’ c(u,,uy). This function expresses the total cost incurred by a distribution tree. In our work, we explore how to allocate this cost among the individual members. 3.1.3 A llocated costs We denote a cost allocation function by af{N , R, M, loc, c); this represents a spe cific cost allocation strategy. Given a network technology defined hy N = {V ,L,T), a group membership defined by M and loc, and a cost structure defined by the link costs c, the allocation function a f defines the cost that will be individually attributed to members of the multicast group; afa{N, R, M, foe, c) denotes the allo cation to member a. For any distribution there may be numerous ways of allocating costs to receivers,® And the focus of our work is on providing a rationale for discriminating among these allo cation policies. We restrict ourselves to policies that fully allocate the costs incurred. We require that: afa{N, R, M, loc, c) = cf{T{N, R, loc{M)), c) V A ", R, M, loc, and c ma&M ®These costs are in no way related to the link-metrics used by routing algorithms to calculate routes in the network. ^Of course, our approach in not limited to the completely static case. For example, one can apply our approach to allocating cost for time slices, amd assuming static behavior within each time interval. The costs associated with transitioning (either membership or topology) is not addressed here. ®See Section 1.3.2.1 for allocating costs to receivers, and not to senders. 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in. Figure 3.1: A simple example of a network. We call this equality the balanced budget condition. Moreover, we restrict ourselves to allocating costs, which means that all allocations are nonnegative (i.e., no receiver is paid for using the network): afa{N, R, Af, loc, c) > 0 V a, IV , R, Af, loc and c 3.2 Exam ples of cost allocation strategies The previous section described our abstract model of cost allocation; here we apply this model and present a few examples of allocation strategies (depicted in Fig ure 3.1). 3.2.1 Equal tree split (ETS) The simplest approach to allocating costs is to merely divide the total tree cost equally among all receivers; we call this the E qual Tree Split (ETS) scheme. In the example depicted in Figure 3.1, all members are allocated the cost [c(ui,U2) + c(u2, V3) -h c(u2, U 4) + c(ui, us)]/9 . 3.2.2 Equed link split dow nstream (ELSD) The ETS policy does not discriminate between those receivers far from the source and those close to the source, and thus does not attempt to hold receivers accountable for 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the costs their individual membership incurs. However, the cost of a particular link is incurred because there is at least one downstream receiver, and so while ail down stream receivers can be considered equally responsible for the cost, all other receivers are not responsible at all. This leads to a different approach to allocating costs, one where the cost of each link is split equally among only the downstream receivers. We call this the E qual Link Split among D ow nstream members (ELSD) scheme.® In the example above, the cost allocated to m l is zero, since she is not downstream of any links, and the cost allocated to m4 is given by c(ut,U2)/7 -f- c(u2, ü3)/3. 3.2.3 Equal next-hop sp lit (E N H S) An approach that is midway between the egalitarian approach of ETS and the emphasis on individual accountability of ELSD is to assign the cost of a link equally to all the next hop links that are part of the distribution tree (with all receivers at that node being treated as part of one other link).^° This is motivated by the idea that we pass costs on to each downstream next-hop (rather than allocate them to the downstream receivers themselves) and then allocate the costs of those downstream links in a recursive fashion. These costs are recursively forwarded until there are no more downstream nodes and costs are fully allocated. We call this the Equal N ext- H op Split (EN H S) scheme. For the example in Figure 3.1, the cost allocated to mi is zero since it is not downstream to any links, the cost allocated to m2 is c(ui, U 2) /6, and the cost allocated to m4 is c(ui,U2)/9 4- c(u2,U3)/3. 3.2.4 U nicast Of course, all of these cost allocation policies should be compared to the unicast costs. The total cost of separate unicast transmissions is higher than the total cost of the multicast transmission, and different allocation policies distribute this surplus differently. Unicast is not a real cost allocation strategy (in the sense of our model), since it allocates to members more than the network costs; however, it ®For those familiar with the concept, this is the Shapley Value of this problem. ^°We give a more precise definition of this scheme in Section 5.2.3. 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. does provide a useful point of comparison.^^ The unicast cost of member a is given by cf{T{N,R,loc{m a)),c). In Figure 3.1, the uniceist cost of m4 is c(ui,U2) + C{V2,V3). ^^Note that if the allocated multicast cost is greater or equal to the unicast cost there may be no incentive to use multicast. 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 4 A xiom atic A nalysis We analyze this abstract model of cost-sharing through the use of axioms. We use as eixioms some possible properties that desirable cost-sharing formula might have. We then investigate the implications of assuming these properties. What additional properties are implied? What forms of cost-sharing rules axe allowed? In Section 4.1 we first identify three basic axioms that describe the process of allocating cost. These axioms describe which aspects of the problem axe relevant to the cost-shaxing formula. We assume that the basic axioms apply throughout the rest of Chapter 4; in Section 4.2 we discuss the implications of these basic axioms and then present a few examples cost allocation policies which satisfy them in Section 4.3. In Section 4.4 we identify a few additional axioms that express different policy objectives of cost-shaxing, and explore the implications of each of these axioms when combined with the three basic axioms. 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.1 B asic axiom s The three basic axioms describe aspects of the cost sharing problem that should be irrelevant to the actual cost sharing formula. We start by observing that a cost-sharing formula should be invariant under arbitrary relabeling of equivalent members; it should not have an intrinsic and arbitrary asymmetry built into it.^ A xiom 1 Anonymity: ^ Members that are indistinguishable mth respect to the costs they impose on the net work must be allocated identical costs. Form al definition: Given any network N = {V, L, T), root i?, member set M , a placement functions loc and any two members ma and mg 6 Mr if cf{T{N , R, loc{M' -f- mo)), c) = cf(T{N , R, loc{M' -f m^)), c) Vc and M ' C (M-ma-mp) th en afa{N, R, M, loc, c) = afp{N ,R,M ,loc,c) Vc Notice the condition Vc and M ' C {M-ma-mp) in the first part of the axiom, which guarantee that equivalency in the costs imposed on the network is not an ad-hoc result of a specific link cost function (like zero cost links) or a specific group membership setup. ^This does not mean that there cannot be systematic asymmetries (e.g., charging professors more than students on a campus network), but these asymmetries should be described as a non equivalency of members (e.g., introducing two classes of members into the formalism). "Notice that this axiom implies that two members located at the same node are equivalent, and must be allocated the same costs. For other cases where members can be considered equivalent see Section 6.3.2. 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Link costs can come from many sources, such as per-packet costs, per-hour costs, and per-connection costs. They can also come from link transmission costs, buffering costs, etc. It is important, in order to avoid the additional complexity and overhead of independently allocating all such costs, that cost allocations would not depend on whether the accounting method allocates these costs separately or jointly. That is, it should not matter if the various components of the link costs are combined into one single cost to be allocated, or if they are separately allocated. This is expressed in the following axiom: Axiom 2 Additivity: Given any two sets of link costs, the sum of their respective cost allocation functions is equal to the cost allocation function of the sum of the two sets. Form al definition: Given any network N = (V ,L,T), root R, member set M , placement function loc, and any two link cost functions cl and c2: af(N , R, M, loc, cl + c2) = af(N , R, M, loc, cl) -{ - af{N , R, M, loc, c2) The cost allocation formula must depend on the underlying network topology. However, it is preferable for this topological dependency to be restricted to factors related to cost. For instance, if we took a single link and artificially broke it into two links (spreading the cost of the link between the two links), the cost allocation should not change. A more general form of this intention is that the cost allocation should only depend on the set of costs incurred by each subgroup. If two networks incur the same costs for every subgroup of members, then they should allocate the cost in the same way. This condition, that two networks incur the same costs for serving each subgroup of members, is actually quite strong; in particular, every unicast cost must be the same, every cost for a pair of receivers must be the same, etc. Any changes in 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the network that preserve this property might well be considered irrelevant to cost allocation.^ Axiom 3 Equivalency: Consider two networks with the same single group of members; if the cost of serving any subgroup of members is identical in both networks, then the allocated costs must be the same. Form al definition: Given a single set of members M and two different network scenarios iVl, R l, loci, cl and N2, R2, loc2, c2: if c/(r(ivi,m,/oci(Af')),ci) = cf{T{N2, R2, loc2{M')), c2) V M' Ç M th en a/(iVl,/?1, M ,/ocl, cl) = af{N2,R2,M ,loc2,c2) 4.2 The canonical form of cost allocation The three basic axioms presented in the previous section greatly reduce the scope of allowable cost allocation policies. In this section, we show that all cost allocation policies satisfying these three basic axioms can be expressed in a very simple canoni cal form. We consider functions F : (0,0)} where we use the symbol Z+ ^This axiom implies that the only relevant aspect of the problem is the induced cooperative game; all other aspects of the topology are irrelevant. 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to denote the nonnegative integers and 3?+ to denote the nonnegative reaJs."* We de fine the family of functions T to be those functions F : — (0,0)} i — » • that sat isfy the properties® (1) zg) -{-22^ 2(21, z;) = 1 and (2) Fi(0,z) = F2(z,0) = 1. Note that the set T is convex: F^G Ç .T =>■ {fiF + { I— fi)G) € ^ f o r ail 0 < ^ < 1. Also, we know that ^ 2(0, 2) = F i(2, 0) = j for z > 0 .® We now use these functions to define cost allocation strategies. Consider a link (uf, Vj) with a cost c(u,-, vj) where there are nd> 0 receivers downstream^ and n„ > 0 receivers upstream. We use a function F = (F„, Fj) € F to determine the fraction of the link cost that is allocated to each upstream or downstream receiver. Members are allocated the following costs: For each upstream member : Fu(nu, nj) * c(u,-, uy) For each downstream member : Fd{riu, rid) * c(u;, vj) The total cost allocated to a member is the sum, over all links, of its share of each link cost. Cost allocation strategies that can be expressed in terms of a function F € F are called canonical strategies. Note that the first condition above in the definition of F ensures that costs are fully allocated: nuFu(nu,nrf)-t-nrfFrf(nu,nj) = 1. It is fairly clear that all canonical strategies satisfy the three basic axioms. More interestingly, all cost allocation strategies satisfying the basic ajcioms are canonical. T heorem 1 A cost allocation formula satisfies the basic axioms if and only if it is a canonical strategy. It is straightforward to verify that any cajionical form satisfies the basic axioms. We now show that any cost allocation formula that obeys the basic axioms can be expressed in the canonical form. Consider any cost allocation formula that obeys ‘ *In case our notation is confusing, the domain of this function is all pairs of nonnegative integers except the pair (0,0). ®The second condition in the definition of .F is unrelated to allocations but is merely used to simplify the expression of Theorem 11. ®For our use in this section we need only have defined F on x (where Z++ denotes the positive integers) but we will make use of the family of functions again in Chapter 5 where we need the larger domain of { Z \ — (0,0)}. ^If there are no receivers downstreeim then this link is not part of the distribution tree and we can ignore its costs. 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the béisic axioms. We begin with the most general case of a network N = {V, L,T) ajid a tree L' = T{N ,R , loc{M)). Since the allocation function is additive, we can restrict our attention to cost functions j which have nonzero cost only on the link (u,-, Uj), and have unit cost on that link. More specifically, we know that * c(u,-, Uj)) = c and therefore: 5^ {afa{N, i?, M, loc, d j) * c{vi, Vj)) = afa{N, R, M, loc, c) ViV, i?, loc, M, a : rria 6 M We must now show that the cost allocations that result from cost functions C i,j can be expressed in terms of the canonical form. Let us now consider reducing one of the additive networks (as illustrated in Figure 4.1) into a single link (u,-,Uj) and the following loc function: , Vj : mp is downstream to (vi,Vj) lod{mp) = \ . V i : Otherwise The subset costs of the reduced network problem are the same as the original prob lem, and the Equivalency axiom requires that the cost allocations be the sajne. The example in Figure 4.1 shows nodes Ui, ug, U 3 merging into a single node ua in the reduced network. The anonymity condition requires that equivalent members be charged the same; in particular, all members at the same node be allocated the same cost. The resulting allocations in this reduced problem are characterized by two quantities, the allocation to the upstream members and the allocation to the downstream members. These allocations can depend on the number of upstream and downstream members, so they are expressed as functions F„(nu,n^) and Fd{uu,nd). These costs must be nonnegative, and the budget balance requirement means that riuFu{nu,nd) +ndFd{nu,nd) = 1. This is precisely the canonical form.® QED ®The conditions Fu(0, nj) = 1 and F<f(n„,0) = 1 in the definition of F are irrelevant to the actual allocations. 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ®2 I V 3 m . 0 m ,, m3,104 Figure 4.1: Merging nodes with no cost link: the Equivalency axiom 4.3 Exam ples o f cost allocation strategies The set T is infinite, and so there are an infinite number of canonical cost allocation strategies. In this section we present several examples of functions F € .F. Two of the functions were already introduced in Section 3.2. Since we know that Fj(0, = ^ for all F € F", we merely describe the functions on the set Since the set F is convex, all linear combinations of the examples below are also in F . 1. Equal Link Split D ow nstream (ELSD) The cost is equally split among the downstream receivers and no cost is allo cated upstream Fu(n„,n<i) = 0 FdiP'Ui'^d) ~ rid 2. E qual T ree Split (ETS) The total tree cost is equally split among all the receivers I Fu(nu,nd) = = 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3. Cost is charged to u p stream receivers Fu{nu,nd) = ^ Fd{n^,rid)= 0 4. C osts are relative to th e num ber of receivers u p stre a m / dow nstream F u ij^ u i ^ d ) — Fdijiui ^d) — + U d^ T ld + nd^ 4.4 Additional axiom s The basic axioms address the issue of what factors should be considered relevant to cost (dlocation. These axioms have substantial reductive power, in that they define a clciss of canonical cost allocation strategies. However, cis the examples above show, one can allocate all costs to upstream nodes, or to downstream nodes, or anywhere in between. Thus, this family of canonical cost allocation strategies incorporates a wide variety of distributive notions. We use the phrase distributive notion to mean standards of equity or justice that allows one to discriminate between allocation policies. Our next step is to examine some additional ajdoms that express particular distributive notions. These axioms can be used to select a subset of canonical allocation strategies. Stand-A lone and R elated A xiom s One such distributive notion is that a member’s cost should reflect the benefits of multicast. Just as the total network cost of a multicast flow is less than the sum of the costs of unicast flows to each member, one might require that each individual allocated cost in a multicast flow never be greater than the cost incurred by the appropriate unicast flow. This yields the following axiom: 38 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Axiom 4 Stand-Alone: The unicast cost of a member is an upper limit on her cost allocation. Form al definition: afa{N ,R ,M Joc,c) < cf{T{N , R, /oc(ma)), c) V N, R, M, loc, c, t U q 6 M The Stand-Alone axiom protects the individual; every individual receiver is guar anteed that joining a group can never cost more than her unicast cost. Assuming users have the power of choice in their network activities, and éissuming some (even minimal) amount of self interest guides them, it is hard to imagine why any user would want to join a shared group of receivers if she risks an increase in her allocated costs. Of course, in a cooperative environment receivers may choose to risk having increased costs if the total cost distributed to the group decreases. Insisting upon the Stand-Alone axiom, when combined with the basic axioms, means that there is one and only one applicable cost allocation strategy;® T heorem 2 A cost allocation function satisfies the basic and Stand-Alone axioms if and only if it is the Equal Link Split Downstream (ELSD) function. Consider any cémonical form F that obeys the Stand-Alone axiom. The Stand- Alone axiom implies that Fu(riu, Ud) = 0 Vriu > 0. Combining this with the budget balance condition n j) 4- Uj) = 1 yields Fd(n„,n<i) = l/ud 'ind > 0 which is the ELSD formula. It is straightforward to verify that the ELSD formula satisfies the Stand-Alone axiom, so the converse holds « is well. QED ®This result is closely related to the standard axiomatization of the Shapley Value (see [56, 54]) in economics. Members attached at the root can be considered dummy members because adding them to a group does not increase the total cost incurred. We can define a dummy member axiom that says that no member located at the root can be allocated a nonzero cost: loc{ma) = R = > afalN,R,M,loc,c) = 0 >/N,R,M,loc,c axid ma E M Theorem 2 continues to hold if we replace the Stand-Alone cudom with the much weaker dummy member axiom. The Equivalency axiom means that only the cooperative game matters (i.e., topology is irrelevant aside from the cooperative game it induces). The basic result due to Shapley is that there is one and only one budget baleinced cost allocation formula satisfying the Additivity, Anonymity, and Dummy axioms, and this formula is now known as the Shapley Value. 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A stronger form of the Stand-Alone ajdora is the “Sharing-is-Good” axiom. This axiom embodies the distributive notion that sharing a multicast tree with more members always benefits everybody. Axiom 5 Sharing-is-Good: The cost allocated to a member never increases when another member joins. Form al definition: o-faiN, R ,M + m^, loc, c) < a/oCA", R, Af, loc, c) V N, R, M, loc, c, m^, and ma E M The ELSD scheme satisfies the Sharing-is-Good axiom, since the share of costs from each link strictly decreases with the number of downstream members (and is independent of the number of upstream members). Clearly any cost allocation scheme obeying the Sharing-is-Good axiom also obeys the stand-alone axiom. These two axioms both describe an upper bound on the cost that can be allocated to a particular member. However, we might also be concerned about the problem of free riders, who are members who do not pay their fair share. According to the stand-alone axiom, the most a member should pay is her unicast cost, and the Sharing-is-Good axiom requires that the allocations decrease as members join. How much can a member benefit without being a free rider? If aU members are located at the same node, then they all pay l/|M |’th of their unicast cost. We suggest that any member paying less than this should be considered a free rider. ^°This is much like the Unanimity bound in economics; see [47, 48]. 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Axiom 6 No-Free-Rider: The cost allocated to a member is never less than 1/|M | ’ th of her unicast cost. Form al definition: \M\ * afa{N, R, Af, loc, c) > cf{T{N, R, loc{rna)), c) 'iN, R, M, loc, c, and ma 6 M Eliminating free riders does not pick out a specific allocation scheme, but does narrow the range of possibilities: T heorem 3 A cost allocation function satisfying the basic axioms and the No-Free- Rider axiom must satisfy: Fu{n,,,nd) < Fd{nu,nd) V(nu,n</) 6 Z++ x Consider any canonical form F. The No Free Rider axiom is obeyed if and only if < Fd{n,i,nd) whenever U d > 0. However, combining this with the budget balance condition n„Fu{nu,nd) + ndFd{nu,nd) = 1 yields nu(Fd(nu,nj) — Fu(nu,rad)) > 0. Thus, whenever (n„,n(i) E Z++ x we must have Fd(nu,nd) > Fu{riu,nd). QED Subset M onotonicity The essential guiding principle behind the Equivalency axiom is that the cost allo cations should depend only on the costs incurred by the various subsets or coalitions of members. Another distributive notion that arises from this principle is that the cost allocated to a particular member should be monotonie with respect to these subset costs. More precisely, if we consider two cost structures cl and c2 (that is, we consider the network N and the members M fixed and we merely consider two sets of link costs), then if for every subset M ' Q M the total cost of serving M ' is no greater under cost cl (compared to c2), then one might require that the allocated costs under cl would not be greater than those under c2. This yields the following axiom: 41 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Axiom 7 Subset Monotonicity: No cost allocation can increase when subset costs all decrease or stay the same. Form al definition: Consider an arbitrary tree L' = T{N, R,loc{M)) and two link cost func tions cl and c2: if cf{T{N,RJoc{M')),cl) > cf{T{N, R, /oc(M')), c2) VM' Ç M then afc,{N,R,M,loc,cl) > afa{N, R, M, loc,c2) Vm^ 6 M It turns out that this axiom, when combined with the basic axioms, determines a unique cost allocation strategy; in fact, only two of the three basic axioms are needed for this result. T heorem 4 A cost allocation formula satisfies Equivalency, Anonymity, and Subset Monotonicity if and only if it is the Equal Tree Split (ETS) formula. Clearly the ETS scheme satisfies the Anonymity, Equivalency, and Subset Mono tonicity axioms. We must now show that any allocation function which obeys the Anonymity, Equivalency, and Subset Monotonicity axioms must be the ETS policy. Figure 4.2 provides an example that follows throughout the proof. Consider any network N = (V,L,T) with a root R, set of members M, location function loc, and cost function c (czise A). From it, we build a second network (illustrated in case B), by adding a new link I' = {R', R) with no cost: N' = {V + R',L + l',r) L" = r{N',R',loc{M)) = L' + l' d = c-hMÆ',/2) = 0} 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. mj V2 = 2 (A) (B) V4 V3 m j (C) Cl+ Cg+ C y f C4 ® 2 * ® 3 » ® 4 © (D) Figure 4.2: Equal Tree Split transformations: cases A,B,C,D Clearly aU of the subset costs are the same under case A and case B, so alloca tions must not change (due to the Equivalency axiom). We now keep the network fixed and consider a new cost function c" (illustrated as case C) where the cost of the whole tree is shifted to {R', R) while the remaining links have zero costs. c''{R',R) = c / ( r x ) c"(u,-, Vj) = 0 V(u,-,uj) € L' Note that no subset cost have decreased, therefore the subset monotonicity con dition implies that no individual allocated costs can decrease. Since the total costs 43 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. have remained the same, the balanced budget implies that total allocated costs must remain unchanged. Under these two constraints, it must be that the allocations for this new cost function d' must be the same as for the old cost function d. Case D is created by merging all the nodes downstream into H, which, according to the equivalency axiom does not change the allocated costs. With all the members in one node (R), the anonymity axiom implies that they all share the cost of the link equally, so, each member is allocated d'(R', R)/IM\ or c/(Z', c)/|M |. This is the ETS policy. QED C ollusion Prevention Another aspect of allocation that is important to consider is collusion. Whenever a cost is shared among clients, it may be possible for several clients to unite, and be represented by a single client who then forwards the data on to them. This is anal ogous to the classic “copy and distribute” security problem. Collusion among some receivers may increase the cost allocated to the other receivers and may decrease the efficiency of sharing the transmission. We would prefer that a cost allocation scheme not encourage collusion among the members. We therefore propose the fol lowing axiom: Axiom 8 Collusion Prevention: The cost allocation scheme does not yield benefits for colluding members. Form al definition: Consider an arbitrary network iV = (V ,T ,r),a root R, a set of link costs c, a set of members M and their location function loc. For each subset M' Ç M and € M': afa{N,R,MJoc,c) < m aSA/' afy{N, R, M — M' + m~f,loc,c) -f- cf[T{Nfioc{m..,)fioc{M' — m^)),c) 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Collusion prevention is a desirable property for cost allocation formulae. Unfor tunately, we show that none of the canonical allocation strategies can satisfies this axiom: Theorem 5 No cost allocation formula satisfying the basic axioms can satisfy the no collusion axiom. Consider any canonical form F and assume that is satisfies the no collusion axiom. Consider a network with a single link, with n„ members at the root and nj. members downstream. Because 5(Fu(5,5) -t- Fi(5,5)) = 1 we either have F„(5,5) > 1/10 or Fd{5,5) > 1/10. Since our proof works with either case, let us assume without loss of generality that f%(5,5) > 1/10. The no collusion condition requires that — l,n j) > 2 + Fu(nu,nrf) for any rZ u , because otherwise one member would collude with another. Recursing this inequality, we find: F^^{n^ — k,nd) > 2^*F„(n„,n(i). Choose = T ld = 5 and k = 4, and then we find that Fu(l, 5) > 2 '* * f^(5,5) > 1.6. This is a violation of the canonical form, thus a contradiction. QED 4.5 D iscussion We started this chapter with three basic axioms, which narrowed the space of cost allocation strategies to the canonical ones. Within this class we discussed how various distributive notions pointed towards different choices. Eliminating free riders restricts us to schemes that allocate more to downstream members than to upstream members. Subset monotonicity leads us to the ETS scheme, while the stand-alone axiom suggests the ELSD scheme. Choosing between axioms is purely subjective, but charging a nonzero amount for a member located at the root seems generally inappropriate. The only canonical allocation scheme that always allocates zero to members located at the root is the ELSD scheme, and so perhaps it is the most natural choice. Our treatment here is completely static. Consider, for a moment, the dynamic policy of allocating to each member the incremental cost of adding them to the distribution tree. The resulting allocations depend on the order in which members joined, which seems rather unfair. It might seem appropriate to then average these 4 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. incremental costs over all arrival orders. Indeed, this averaging produces the ELSD allocations.^^ In this chapter we discussed various cost allocations schemes from an cixiomatic perspective. The next chapter discusses mechanisms for implementing these cost allocation schemes. ^^This is the standard motivation for the Shapley Value. 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 5 A ccounting M echanism s In this chapter, we use the term accounting schemes to denote mechanisms for implementing cost allocation schemes. First, we discuss the general structure of one class of accounting schemes we call one-pass. We then describe two different models implementation models of such schemes, models 1 and 2, which differ in the information provided about downstream members. Each of these models is examined according to the central question raised throughout this chapter: what forms of cost allocation schemes can this family of accounting mechanisms support? 47 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.1 One-pass accounting schem es We have made the fundamental assumption that costs are zdlocated among the multicast receivers. Because the number of receivers can become quite large, and widely-dispersed geographically,^ the key concern in designing accounting mecha nisms is scalability. It is important that the traffic load imposed by the accounting mechanism on any particular link should not increase (without bound) with the size (in terms of numbers or in geographical dispersion) of the multicast group. Thus, scalability concerns rule out any kind of centralized accounting, and so we must turn to a more decentralized approach. In this work, we consider only the family of one-pass mechanisms whereby the accounting control messages make a single pass from the source down the multicast tree to all receivers. While this is not the only scalable accounting mechanism one might imagine,^ it certainly seems among the most natural. In this one-pass method of accounting, nodes allocate costs to mem bers as the accounting message passes through them. The information used to make the allocation decisions comes from two sources. The first source of information is multicast routing (and perhaps the reservation establishment protocol if the costs are related to reservations), which provides information about the downstream links. Traditional multicast routing only provides information about whether or not there exist members downstream of a particular link. We call this m odel 1. It is possi ble, perhaps only because it enables better allocation of costs, that multicast routing could provide the exact number of members downstream of each link. We call this m odel 2.^ If the link costs are tied to reservations then this information about the number of downstream members maldng reservations could be provided by the reser vation establishment protocol. We will consider both models in what follows. As we shall see, there is an important difference in the functionality that can be achieved in ^The geographic dispersion is important because it means the amount of information needed to describe the tree topology is also growing. ■For instance, one could design an accounting method that involved two passes of control mes sages, one downstream and the other back upstream. Also, one could use an iterative accounting method where the control messages continued to circulate until zin equilibrium had been reached. ^To do any form of cost allocation we must be able to identify all members at a node, if for no other reason than to give them the feedback about their allocated costs. The question is then which protocol will carry these numbers upstream. It appears to be simple to modify most multicast routing protocols to carry the cumulative membership numbers upstream once the number of local numbers is available. 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. the two models.'* The second source of information is the accounting message itself. The design of a one-pass accounting mechanism essentially reduces to the question of what information is carried in the accounting message sent downstream. To ensure scalability, this information cannot grow with the size of the multicast group, nor with the number of links traversed. This prevents us from carrying detailed infor mation about each upstream link cost and each member’s allocated cost. Instead, we choose to carry only a single piece of information in the accounting message: the unallocated or residual cost passed down from the upstream node. While this is not the most general form of accounting message,® it seems a natural and simple choice. Thus, with this form of accounting message, the costs are allocated with the following process. The accounting message arrives at a node on the incoming link from an upstream neighbor, carrying the upstream residual cost; we will call this the input cost to the node and let in{vj) denote the input cost arriving at the downstream node vj. The cost allocation function determines how much of this cost is allocated to each of the local members and how much is passed down to each of the downstream next-hops. We wiU call the costs that are passed on the residual o u tp u t from a node, and let out{vi,Vj) denote the costs that are passed on from node Vi to downstream node Vj. The sum of all residual outputs plus the sum of all locally allocated costs must be equal to input cost as a result of the balanced budget rule.® When an accounting message is forwarded to the downstream neighbor, the cost of the link connecting the two nodes is added to the residual costs and this sum is carried in the accounting message as input costs to the next-hop node: thus, in{vj) = c(u,-, Vj)-\-out{vi^ vj) when vj is a next-hop downstream of u ,-. At leaf nodes, all costs are allocated to the local members. At nodes with no local members, all costs are passed down to the downstream next-hops in the accounting message. One-pass accounting is a distributed accounting scheme. Independent cost allo cation decisions are made by each individual node based on the information provided to it by multicast routing (either model I or model 2) and the accounting message. '‘From the point of view of implementation of the accounting schemes themselves, model 1 and model 2 are essentially equivalent. ®One could, for instance, include information of the previous five upstream links. ®It is straightforward to show that if there is one node with a locally unbalanced budget then one cannot guarantee that the overall cost budget is balanced. 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We assume that no other information about topology or group members can be fac tored into the allocation decision. For model 1, since a node can make no meaningful distinctions between downstream links, we require that the residual costs passed on to each next-hop are the same: out{vi,Vj) = out{vi,Vk) for all links (u,, uy) and {vi,Vk) in the distribution tree. We further assume, in both model 1 and model 2, that all nodes must implement the same allocation rules. In order to achieve a consistent allocation scheme, all nodes, if given the same information, must produce the same allocation. We will refer to cost allocation schemes that can be implemented with a model 1 one-pass accounting mechanism as model 1 allocation schemes, and similarly for model 2. The basic one-pass structure of cost accounting imposes some significant restrictions on what cost allocation formulae can be supported. In particular, such one-pass accounting schemes can only support cost allocation schemes that satisfy the Stand-Alone axiom:" T heorem 6 Given a tree T{N,RJoc{M)), a set of link costs c, and a one-pass accounting mechanism, no member can be allocated a cost greater than her unicast cost. From the definition of the one-pass model we know that: (1) nodes are budget balanced so their output and allocations are bounded by their input, and (2) in{vj) = c{vi,Vj) -t- out{vi,Vj) for each vj downstream to u ,-. Thus, in{vj) < c{vi,Vj) -t- in(vi). If we iterate this inequality for each node along the path from R to any node Vk, and collapse the inequalities, we get the following result: in(vk) < cf(T(N,R,Vk),c). QED We axe interested in how many of our original axioms are consistent with our one-pass family of accounting mechanisms. Before we consider models I and 2 sep arately, we can rule out one axiom that does not apply to either of them: stronger result holds. No subset M' Ç M can be allocated a cost that is greater than their subtree cost: ^mceAf'^fa(i^,R,Af,loc,c) < cf(T(N, R, loc(M')), c) ViV, R, M, loc, M' Ç M, and c. This means that all one-pass accounting schemes produce results that are in the core (see [57] for a definition). 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “ l ® 2 V4 «1 “ 2 (Cl) (C2) Figure 5.1: Subset monotonicity vs. one-pass model T heorem 7 No cost allocation scheme implemented with a one-pass accounting mechanism can satisfy the subset m onotonicity axiom. Consider an accounting scheme that satisfies the subset monotonicity ajciom. Consider the example in Figure 5.1 of a single tree T{N, R, loc{M)) with two different link cost functions: cl, c2. The cost allocations for cl are straightforward: afi{) = a/2 0 = 10. Because the total cost of the tree remains the same, v/hile no subset cost decreases, subset monotonicity implies that the cost allocations must be the same for cl and c2. To achieve this allocation for c2 it must be that out{v2 ,vz) = 10. But we must have out{v2 ,vz) = out{v2 ,V4) which violates the local budget balance. Contradiction. QED We first discuss model 1, mainly because it is simpler, and it relies on topology information which is available from virtually any mainstream multicast protocols (i.e., the existence of at least one member downstream to a specific link). As our discussion reveals, while simple, model 1 only supports seriously flawed allocation policies. This lead us to model 2, which does not have the same flaws as model 1, however, it requires some additional information. This additional information (i.e., the number of members downstream to a specific link) may only be available from newer multicast or resource reservation protocols. 5 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. c(v1, v2) ® 3 Figure 5.2: one-pass, model 1 vs. Equivalency 5.2 M odel 1 We now consider accounting mechanisms in the context of model 1, where multicast routing only indicates which links have downstream members but not how many members are there. 5.2.1 R educed B asic A xiom s We would like to invoke the basic axioms presented in Section 4.1. Additive and Anonymous cost allocation schemes can be supported (as we shall see in examples) by model 1 accounting schemes. However, we find that the Equivalency Axiom is not consistent with model 1. Theorem. 8 No cost allocation formula that is implemented by a model 1 one-pass accounting scheme can satisfy the Equivalency Axiom Consider a model 1 one-pass accounting scheme that satisfies the Equivalency axiom. Consider the following example of a network illustrated in figure 5.2, where c(ui,U2) > 0 and c{v2,vz) = c(u2, u^) = 0. The Equivalency axiom imphes that the cost allocations to members on vz and V 4 should be the same: a/i() = a/zO = o/sO- 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. However, the definition of model 1 implies that in(vz) = in{v^) = , Therefore, the cost allocations cannot be the same. Contradiction. QED Thus, model 1 accounting schemes are necessarily dependent on the physical topology, in contrast with the topological independence of the Equivalency axiom. For model 1 we will still require that the reduced basic axioms of Anonymity and Additivity hold, but must relinquish the Equivalency axiom. In the next section we develop a canonical form for model 1 allocation schemes that obey these two axioms. In passing we should mention that these reduced basic axioms lead to the same impossibility result about collusion: T heorem 9 No model 1 cost allocation formula satisfying the reduced basic axioms can satisfy the no collusion axiom. This proof is identical to the one in theorem 5 replacing (Fu,Fd) by (F), n„ by ni and n^ by Ur. QED 5.2.2 The one-pass Canonical Form Consider any model 1 allocation scheme that obeys the reduced basic axioms. At leaf nodes, all costs must be allocated equally to local members. At nodes with no local members, all costs much be passed on equally to all downstream links. Thus, the only design freedom left is how much of the residual cost to allocate to the local members and how much to pass on to downstream members when both are present. We can express the family of possible design choices with the one- pass canonical form of cost allocation formulae (supporting the model 1, one-pass accounting scheme). Each one-pass canonical form is associated with a function F = (F), FV ) Ç . F in the following way. Consider a node u ,- with an input cost of in{vi). If there are n/ local receivers m d U r next hop nodes, the allocated costs are: For each local member on u ,-: F)(n/,nr) * in{vi) For each next hop node vj : out{vi,Vj) = Fr{ni,nr) * m(u,-) All model 1 allocation schemes obeying the reduced basic axioms can be expressed in this form: 53 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. T heorem 10 A model I cost allocation formula satisfies the reduced basic axioms if and only if it can be expressed in the one-pass canonical form. It is straightforward to verify that any one-pass canonical form satisfies the re duced basic axioms. We now show that any model 1 cost allocation formula that obeys the reduced basic axioms can be expressed in the one-pass canonical form. Similar to the proof for theorem 1, we begin with the most general case of a network N = (V,L,T) and a tree L' = T{N,R,loc{M)). Since the allocation function is additive, we can restrict our attention to cost functions c,j which have nonzero cost only on the link (vi,vj), and have unit cost on that link. We must now show that all cost allocations that result from cost functions c,j can be expressed in terms of the canonical form. The anonymity axiom implies that all local member are allocated identical costs. The definition of model 1 requires that the residual costs passed on to each of the next hops are the same. These allocations can depend on the number of local members and downstream next-hops, so they are expressed as functions Fi{ni,Ur) and Fr{ni,nr). These costs must be non-negative, and the budget bzdance requirement means that Fi{ni,nr) + nrFr{ni,nr) = 1. Using Additivity, we can show that the allocations must be proportional to the incoming costs, so: For each local member on u ,-: Fi{ui, n^) * in{vi) For each next hop node Vj * : out{v{, vj) = Fr{ni, Ur) * in(v{) In model I the input costs to the next hop vj include both residued cost and the cost of the link connecting them: in(vj) = m(u,) * Fr(ni,nr) -f c(vi,vj). T his is precisely the one-pass canonical form. QED While the one-pass canonical form appears very similar to the canonical form discussed in Section 4.2, there are important differences. The previously discussed canonical form expressed how the cost of a particular link was allocated to aU up stream and downstream members. Here, the canonical form only describes the allo cation to local members and to downstream finks. To find the resulting allocation the one-pass model, residual costs are costs that are rdlocated individually to each immediate downstream neighboring node 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to ali members we must recursively iterate this formula down the tree. Thus, it is much harder to understand what allocations will result from a particular one pass canonical form. 5.2.3 Exam ples The one-pass canonical form allows for an infinite set of possible allocation strategies. Below we list a few examples. Since we know that F/(n/,0) = ^ and Fr(0,Ur) = ^ for all ni^Tir > 0, we merely describe the allocations on the set Z " \ ,. 1. Local m em bers pay nothing Fi{ni,nr) = 0 Fr(jl[,Tlr) — 2. Local m em bers pay everything Fl{ni,Tlr) = — ni 3. All locals are considered as one next hop (ENHS): 1 F l(ni,Tlr) = F r ip - li'flr ) ~ ni * {U r -I- 1) 1 T lr -f- 1 4. Local m em bers and N ext H ops are allocated identical costs: Fi{ni,Tir) = Fr{ni,nr) = — ; — ni -f U r 5. Equal Split betw een all th e local m em bers and all th e next-hops: I Fi{ni,nr) = Fri^rili^r) ~ 2*m 1 2 * Ur 00 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6. M ajority Loses: if ni> T ir : Fi{ni,Tir) = — and Fr{ni,nr) = 0 ni if ni <Tir : Fr{ni,rir) = — and Fi{ni,rir) = 0 Hr i î Ti[ = Ur : F i{n i,rir) = F r ( n /,r ir ) = ^ 5.2.4 A dditional A xiom s We already know, from Theorem 6, that all the one-pass allocation schemes must satisfy the Stand-Alone axiom. However, not all such cost allocation schemes obey the Sharing-is-Good axiom. T heorem 11 A model 1 cost allocation formula satisfies the reduced basic axioms and the Sharing-is-Good axiom if and only if the functions Ft{ni,nr) and Fr{ni,Ur) are nonincreasing on — (0,0)}. It is straightforward to show that the Sharing-is-Good axiom conditions are ex actly identical to the no-increasing formulae conditions. When adding a local mem ber to a node already on the distribution tree, we must have: Fi{ni + l,nr) < Fi(ni,nr) V(n;,nr) € Z++ x Z+ Fr{ni + I, nr) < Fr(nj,nr) V(n;,nr) € Z+ x Z++ When adding a member to a node which was not on the distribution tree, at the nearest node on the tree we must have: Fi{ni,Ur + 1) < Fiini.Ur) V(n/,nr) G Z++ x Z+ F r{n i,U r + 1) < F r(n;,72r) V(nf,7%r) G Z + X Z++ When we combine these equations with the second condition in the definition of F we get the non-increasing condition on all of {Z^ — (0,0)}. QED Note that of our examples, only the last one fails this test. Thus, all model 1 allocation schemes obeying this mild restriction ensure that the benefits of multicast are shared among all receivers. 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. “ 1 Figure 5.3: No-Free-Rider ajdom in model 1 Recall that in Theorem 3 a wide variety of canonical cost allocation policies satisfy the No-Free-Rider ajdom. In particular, the ELSD scheme, satisfies the No- Free-Rider eixiom. However, no model 1 allocation policies satisfy the No-Free-Rider axiom. T heorem 12 There is no model 1 cost allocation formula that satisfies the reduced basic axioms and the No-Free-Rider axiom. Assume there is a model 1 cost allocation formula that satisfies the reduced basic axioms and the No-Free-Rider axiom. In Theorem 10 we have shown that all model I cost allocation formulae obeying the reduced basic axioms can be expressed in the one-pass canonical form. Consider the tree detailed in figure 5.3: with no members in Ü 2, Fr(0,2) = 1/2 for all formulae, resulting in in{v4) = 6. With no next-hops downstream of u4, F (2 ,0) = 1/2 for all formulae, maJcing the allocation to each member on exactly 3 which is less than 11/3 (unicast cost/|M |). QED As long as our functions F/, F- are nonincreasing (so that the Sharing-is-Good axiom is obeyed) we have little to guide us in our choice of canonical model 1 allo cation schemes. Allocating everything to the local members is unfair, as is passing all costs on to the downstream links. In a very rough intuitive sense, fairness seems to dictate that local members individually are allocated no more than is passed 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. on to the individual links {Fi{ni,Tir) < Fr{ni,nr)) and the set of local members as a whole are allocated at least as much as is passed on to the individual links {niFi{ni,Tir) > Fr{ni,Tir)). There is wide latitude between these two extremes of treating local members each as a downstream link, and treating the collection of them as a downstream link. How can we choose among the various possibilities that lie within the spectrum < Fi{ni,rir) < Fr(n;,nr)? One possibility is to require that the cost allocated to members not depend not on the exact number of members at cdl other nodes, but only on the set of nodes where there are members. This condition makes sense in the context of model 1, since it does not provide these numbers. Moreover, the contexts in which model 1 might be deployed, it may not even have this information at the local level; the costs, rather than being assigned to individuals, might really be assigned to the nodes (subnets) at which members reside. For instance, all costs allocated to members on an ethemet at USC would be tissigned to USC rather than to the individual members. This would allow current multicast protocols, which do not keep track of individual members, to be consistent with cost allocation. Given that the number of members at a particular node is not known, the allocation to other members should not depend on it. This requirement means that Fr(n;,nr) = Fr{l,rir) for all n; > 0, and thus narrows the spectrum — < F/(n;,nr) < Fr{ni,rir) down to the single point = Fi{ni,nr), which is merely the ENHS scheme. We did not embody the considerations in the previous two paragraphs in axioms, because the distributive notions were significaütly less general and compelling than our previous axioms. We fully admit that this line of reasoning, which leads to ENHS, is much weaker than our previous results, but we do not see any other general principles at our disposal. This is largely because the allocations that result from model 1 have unavoidably poor properties (free rider, no equivalency, etc.) and so it is hard to formulate desirable distributive notions that are achievable in this context. 5 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.3 M odel 2 As we stated above, we axe interested in the extent to which these accounting mech anisms can support cost allocation formulae that obey our previous axioms. As we show below, model 2 can support the basic axioms presented in Section 4.1. In fact, there is only one model 2 cost allocation formula that obeys the basic axioms: T heorem 13 ELSD is the only cost allocation formula that obeys the basic axioms and that can be implemented with a model 2 one-pass accounting mechanism. This follows trivially from Theorems 6 and 2. How is the ELSD formula implemented? Consider some node u ,- in the distribu tion tree; we let tmem(u,-) denote the number of members located in the sub-tree rooted at V { and recall that in(u,) denotes the input costs in the accounting message arriving at u,-.^ The allocated costs are: For each local member on u, For each link {vi,Vj) For each next hop node vj in{vi)ftmem{vi) out{vi, Vj) = in{v{) * tmem{vj)ftmem{vi) in{vj) = out{vi, Vj) -f- c(u,-, vj) Notice that the residual costs passed on to next-hops are proportional to the number of receivers downstream. The cost of the connecting link is passed on fully to the downstream next-hop. 5.4 D iscussion In Chapter 4 we discussed a general axiomatization of allocation policies. The ELSD scheme emerged as the most attractive scheme. We then turned, in this chapter, to issues of implementation. We discussed two different models in this chapter. Model 2 can implement the ELSD scheme, and in fact this is the only model 2 scheme consistent with the basic axioms. So, if we adopt model 2 in our implementations. ®A node V{ knows the value of tmem{vj) for all immediate downstream members because this is a basic property of model 2. The node can calculate tmem[vi) by adding up all the tmem{vj) for all immediate downstream members and then adding the number of local members. 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. there seems little question that ELSD would be the most appropriate allocation policy. However, when we use model 1 we are faced with a much more confusing situa tion. We cannot achieve the desired degree of topological independence, nor can we prevent free riders. There axe few distributive notions, besides shaxing-is-good and stand-alone, that we can achieve. We do present an intuitive line of reasoning that suggests that ENHS is the best of this rather sorry lot of allocation policies. How to choose between these two models? From the perspective of the accounting protocol needed to realize them, the difference in implementations between models 1 and 2 is very small. The key difference between the two models is in the availability of the exact number of local members; once that number is available, it seems fairly straightforward to provide it upstream either through multicast routing directly, through the reservation establishment protocol, or even through a separate set of accounting control m essag es.If costs are tied to reservations, then model 2 is quite practical since the number of local members is already known to receiver-initiated reservation establishment protocols. However, most multicast routing protocols do not determine the number of local members and so if costs are applied more gener ally we are faced with the tradeoff between the increased implementation difficulty of model 2, with the correspondingly better allocation policy, and the significantly easier implementation of model 1, which comes with a seriously flawed allocation policy. An intermediate point is to keep track of the cumulative number of domains with internal members, instead of the number of individual host members. Only border routers would propagate the member-domain counts upstream, eliminating the need for interior-router modifications and thereby sidestepping much of the im plementation difficulties. The discussion in this chapter focused exclusively on the one-pass accounting mechanism. There axe a wide variety of other approaches available; why naxrow consideration to this paxticulax family? From a purely mechanistic perspective, the one-pass mechanism has several desirable properties: simple, easy to implement, and the number of local members is available, but multicast routing does not propagate these numbers upstream, then one could add such a function directly to the accounting mechanism and this would necessitate a second set of accounting control messages traversing up the distribution tree. This can be viewed as an alternative implementation of model 2 since, as we observe below, the basic allocation process can be adequately handled with a one-pass mechanism. 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. scalable (i.e., the state carried in the accounting message does not grow with the number of members or with the size of the distribution tree). In addition, in the con text of model 2, the one-pass accounting mechanism can implement the ELSD policy which, on purely axiomatic grounds, was identified as the most natural allocation policy.The most obvious drawback with the one-pass accounting mechanism is that when combined with model 1 it cannot implement allocation policies that obey the Equivalency axiom. While we do think it important to explore other accounting mechanisms, and we plan to do so, we believe that it is essentially impossible to achieve Equivalency if allocations must be done without knowledge of the number of downstream members. That is, we believe that the key factor preventing Equiva lency is the difference between model 1 and model 2, not the features of the one-pass mechanism itself. should note that we have also analyzed a two-pass accounting mechanism, where the first pass goes upstream from receivers to senders, and the second pass goes downstream from senders to receivers. In the context of model 2, this two-pass mechanism is capable of implementing all canonical cost allocation strategies. However, since the ELSD policy seems the most natural policy, and it does not require the extra complication of the two-pass mechanism, we will not discuss the two-pass mechanism here. 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 6 E xtensions to the basic network m odel Our basic network model, presented in Chapter 3, depicts multicast as single, source- rooted distribution trees, computed from unicast routing, with a single quality of service (QoS). The simplicity of the model allowed us to use analytical approach and to present a simple mechanism to achieve the desired cost allocation. However, this basic model may be extended to accommodate more variety in network tech nology: in this chapter we discuss several options for the quality of service offerings, the routing protocols used, and the reservation model, and network hierarchy. In particular: • Multiple levels of QoS are supported by protocols that allow for a certain degree of heterogeneity in the QoS requested by receivers (e.g., RSVP). • Some protocols extend the multicast model. Protocols like PIM and CBT have the ability to support multicast distributions via shared trees. • Some reservation protocols (e.g., RSVP reservation styles) allow sharing net work resources among multiple sources (referred to as “Shared Channels”). • Large networks tend to be organized hierarchically, which means that nodes may belong to different levels of network hierarchy and may be hidden within “network clouds”. 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.1 M ultiple quality of service (QoS) levels In the basic network model, all members are assumed to request the same quality of service, and therefore, are all equivalent (except for their location). However, when we extend the model to allow heterogeneity between members, and allow receivers to specify their desired QoS, then if these different QoS levels incur different network costs, the members are no longer necessarily equivalent; ^ Extending the model to accommodate multiple QoS’s affects the canonical form that was introduced in Section 4.2. With / distinct levels of QoS, the canonical form is modified to define the family of functions J- to be those functions F : i — » • that satisfy the properties: (1) J2lLi^iF{{z) = 1 and (2) = 0 = > ■ Fi{z) = 1. We use a function F = (Fj, F j, • • • F„, Fj • - • F„, Fj) 6 .F to determine the fraction of the link cost that is allocated to each upstream or downstream receiver of level 1 < z < /. These functions may depend on the number of upstream and downstream receivers of each QoS level; "L "j- Given a link (u,-,Uj), a member with QoSi is allocated the following costs: For each upstream member : F^(n„, nj, • • • n|,,n^ • • • * c(u,-, U j) For each downstream member : Fl{n\,n\, • ■ • nj^, nj njj) * c(u,-, Vj) This raises an issue that is in some sense orthogonal to the one considered in our basic network model. The basic model considered the issue of how to share costs between equivalent users at different locations. Having multiple QoS’s raises the issue of how to share the cost between several members who are in the same place but request different QoS levels.^ If the set of qualities of service is completely ordered^ then the problem reduces to what has been called in the literature the airport game (see [37]) where the cost of the link is the cost associated with the ^The equivalency among members was implied by the anonymity eixiom (Section 4.1). With location being the only property in which members could differ, members residing on the same node must be equivalent. If members differ in their requested QoS, only members located at the same node and who requested the same QoS can be considered equivalent. ■Combining the two issues to have different QoS’s at different locations can only be done after one has solved the two problems independently. ^Even when the set of QoS levels cannot be fully ordered, there may still be some single, ad-hoc metric that applies to all service levels, such as incurred costs, that may be used to fully order all QoS levels. Using such ad-hoc metric is not axiomatically based, since we do not expect everyone throughout the network to use the sam e cost arrangement (metric) between QoS levels. 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. highest QoS requested.'* Here the Shapley value of this game is easy to compute; it is very much like the ELSD scheme in that every user shares equally the incremental cost of all levels less than or equal to their requested level. This cost allocation formula, for this special form of the problem, can be axiomatized in a variety of ways (see [49]) and appears to be a rather natural choice. In the context of scalable, receiver based reservation protocols (e.g., RSVP) the set of QoS’s must at least be partially ordered.® However, if the set of QoS’s is not fully ordered, the problem becomes significantly more complicated, and it does not seem to have an equivalent natural solution. We do not address this problem in our work; we suggest that the problem is mainly a local issue; i.e., how does one split the costs of the local link between the multiple QoS levels that have merged to create the local QoS level serviced on that hnk. Being a local issue allows local entities to apply different criteria without having to consider global policies. 6.2 M ulticast distribution m odel Our basic network model follows the most wide spread form of multicast routing protocols (manifested by DVMRP [6, 5, 7], MOSPF [50], or PIM’s SPT’s [22, 23,26]), by defining multicast distributions as source rooted trees, computed from unicast routing. Newer protocols use different models for their distribution. CBT (Core Base Trees) [6] advocates using a shared tree for all sources (core rooted rather than source-rooted trees). PIM (Protocol Independent Multicast)[22], in its sparse mode, enables mixing, within the same multicast group, source-rooted shortest path (SPT) routes for some senders and a single shared tree for all other senders of the group. Our theory only assumes that the route taken from a particular source to a particular ^Strangely enough, an analogous problem was presented in the ancient Jewish books of the Talmud and Mishna [2, 75]. Even more striking, the discussion there reached identical conclusions as in the more contemporary airport game. ® In RSVP, when two receivers request a reservation to the same flow, for the same link, their requests are merged into a single reservation. The minimal requirement for merging receiver reser vations is that the QoS resulting from the merger would be greater or equal to the QoS of each of the merged reservations, (see [8]). Consider the case of two QoS levels that depend on two param eters {Bandwidth, Delay bound]; QoSi = [High, Loose] and QoSo = [Low, Tight], QoSi and Q 0 S2 may be merged to form Q 0S3 = [High, Tight], with partial ordering Q 0 S3 > QoSi and Q 0 S3 > Q 0 S2 even though QoSi and Q 0S2 cannot be ordered. 64 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. receiver is independent of the group membership (i.e., the route will be the same to a specific group member regardless of who else has joined the group). This remeiins true for both CBT and PIM, and thus our results apply.® Another aspect of routing which can invalidate our theory is the ability to request alternate routes. Typically the collection of independent alternate routes does not automatically compose a well formed tree; when an a new alternate route is being established the route is followed until it hits the shared tree. This means that the resulting tree depends on the current membership, and the set and order of requests for alternate routes. The relationship between reservation protocols and alternate routes in multicast distributions is not fully understood yet, and is currently being investigated in [72]; The impact of such alternate routes on the basic network model was not explored in this work, and is left for future work. 6.3 M ultiple senders In the basic network model costs are allocated to receivers of a single flow. If link costs are computed as a function of actual traffic, (packet counting), costs are naturally associated with individual flows based on source/destination addresses, flow-id^, or other fields embedded in the packet header. However, if link costs are computed based on reserved resources, the distinction between individual flows may become more relaxed: some resource reservation protocols support the concept of “shared channels” as they allow a single resource reservation (channel) to be shared by multiple flows. (See RSVP’s WildCaxd Filter (WF), Shared Explicit (SE), and Dynamic Filter (DF) in [8]). 6.3.1 Shared channels A typical example of a shared channel application is audio conferencing, which is supported by RSVP’s WF or SE styles. Here, the underlying assumption is that application semantics (human capabilities) require, in effect, that only one source ^Although this assumes that the route used when computing the stand-alone cost is chosen using multicast, rather than reverting to a unicast route. ^IPv6 supports locally unique flow IDs, selected by the sender. 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. IS participants SO participants Figure 6.1: Shared channel scenario: audio conferencing with WF reservation style speak at any given time, regardless of the number of participants. Since there is no reason to reserve for more than a single source on any link, RSVP can limit the resulting reservation, and conserve network resources, (see [45]). Figure 6.1 illustrate a simple case where a conference spans two sub-nets (A and B) connected through a single link (A, B). If audio requires a reservation of size X, then regardless of the number of participants, the conference would require the same resource reservation, of size X, for each direction on the link. In this section, we investigate how the overall cost of the shared channel is al located between the participants of the conference. Let us re-visit the three basic axioms from Section 4.1. Applying these basic axioms over the basic network model produced the canonical form of cost allocation. Both the Additivity and Equiva lency axioms are not aÆected by having multiple senders, however, the Anonymity axiom must be examined more closely. In the basic network model, which allows only a single source, the Anonymity axiom was used to declare equivalency between all the members located on the same node. What are the effects of allowing multiple senders to share a single reservation? First, let us consider the simplest extension: consider the case of a shared channel for multiple sources, where all the receivers reserve for the same set of sources. In this case, a shared channel is analogous to a single flow: all the receivers located on the same node also reserve the same set of sources, and therefore, they are considered indistinguishable and equivalent. However, when receivers are allowed to reserve for different sets of sources then the 66 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Si Legend: — Link Q Node — SVi muliicast tree S2*s muliicast tree m l Group member Figure 6.2: Shared channel scenario: audio conferencing with WF reservation style problem becomes more complex: receivers that reserve different set of sources, are no longer automatically assumed to be equivalent simply because they reside on the same node. Figure 6.1 illustrates a shared channel example, where subscription and location are not equated, and where the location of upstream or downstream is not only irrelevant, but also impossible to determine. Members mi and m2 reside on node Ü 3. Member m % reserves for 5i traffic only, while member m2 reserves for both S\ and S2 . With respect to link (ui, U 3) both m % and m2 are subscribers, and with respect to link (^2,^3), m2 is a subscriber, while m % is a non-subscriber. An interesting but unanswered question is: is mi upstream or downstream to the shared link (ui,U3)? The answer is not very surprising: Considering 5i, mi is downstream, considering S2 , mi is upstream, and considering the shared link, it is impossible to tell. 6.3.2 T he canonical form o f shared channels The Anonymity axiom defines individual members as equivalent if the costs they impose on the network are identical, irrespective of the link cost function and group membership of other members. In the shared channel case, the costs imposed on the network due to a reservation by any given member are unrelated to the number of sources sharing the channel. Let us define the term subscription in the context of shared channels: a receiver subscribes to a shared channel if it reserves for at least one upstream source over that channel. When we apply the Anonymity axiom to 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. shared channels we reach an interesting result: anonymity determines that all the receivers that subscribe to a chajinel axe considered equivalent. The costs imposed by non-subscribing receivers are zero, therefore, they axe all considered equivalent as well. The canonical form for shared channels is very similax to the one that was developed for single-source flows. The only difference is that in the original one, the distinction was made between upstream and downstream receivers, while here, we make the distinction between subscribers of the shaxed channel, and non-subscribers. The Shared-Channel Canonical form has the following form: For each subscribing receiver : n„) * c(u,-, Vj) For each non-subscribing receiver : F’ „(n„ n„) * c(u,-, Vj) In an interesting observation we can see that the distinction between subscribing and non-subscribing members is actually a more general distinction than the one between upstream and downstream ones. In the specific case of a source-rooted multicast tree, these two concepts are identical: all the subscribing receivers axe by definition downstream, and all the non-subscribing receivers are upstream. This observation should not come as a surprise considering the fact that the original three basic axioms remained unchanged, and apply to the shaxed channel network model as well as to the original basic network model. 6.4 Cost allocation over network clouds In the basic network model all nodes axe assumed to be equivalent. However, large internetworks tend to be organized hierarchically and when individual nodes be long to different levels of network hierarchy they can no longer automatically be considered equivalent. If cost allocation is performed at some level of the network hieraxchy nodes in a lower level may be “hidden” within “network clouds”.® We focus our attention to network clouds that axe formed by nodes that do not paxtici- pate in the cost allocation protocol. We consider two distinct issues: (1) How hard is it, mechanistically, to implement cost allocation over clouds and (2) what are the effects of network clouds on cost allocation properties and incentives. *For example, inter-net cost allocation can be done between boundary nodes, hiding intra-net details. 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Legend: Link Tunnel Node m2 m 5 m 6 m 7 vlO ml, m 3 m S m 6 m 7 vlO Case A: A Network cloud Case B: Tunneling though the cloud Figure 6.3: Cloud scenario: setting tunnels across clouds 6.4.1 M odeling network clouds Most internet protocols deal with network clouds through the common concept of “tunneling” (see [67]). Tunneling is achieved by creating virtual links which cross the cloud and connect pairs of boundary nodes. In this section we discuss how the concept of tunnels, and the distinction between virtual and physical links affects the basic network model. Figure 6.3 illustrates a cloud scenario. Consider the following transformation from case A to case B: first, we ignore (remove) all the information relating to the cloud’s internal nodes and links. Second, we set up tunnels between boundary nodes pairs, according to the routing function of the original network model;^ this implies that the routing function is basically left unchanged. ®If the original multicast tree has an in-cloud branch between two boundary node u, and vi (for instance, Vi,Vj,Vk,vi), a tunnel (v,-,vi) is created and added to the basic model. 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. This transformation replaces the unfamiliar cloud with a set of virtual links that can be mapped into the basic network model. Next, we ask ourselves, what is the cost associated with tunnels? In the basic network model, the cost of links (cost function) is considered a local issue: the network model accepts the cost function eis input and assumes that costs are determined locally and independently by link administrators. The model makes no assumptions and imposes no restrictions on whether the network topology is physical or virtual, which means that cost functions axe not limited, and could represent either physical or virtual link costs. The technical issue of how the local cloud administration calculates the cost of tunnels was not investigated in our work, simply because, like the local mechanism to determine physical local link costs, it is completely transparent to the basic network model. 6.4.2 Cloud incentives Network clouds, like axiy other autonomous domain, have the ability and sometimes, the incentives to hide and lie about their internal details; why would a cloud reveal that it has more than one member? We have discussed this general concept when we presented the Collusion Prevention axiom. Theorem 5, proves that there is no cost allocation formula that can annul the benefits of such collusion; this result suggests that if collusion is to be prevented, it must be achieved by means other than through cost allocation schemes. It is conceivable that legal restrictions would alleviate this problem; autonomous domains axe usually a paxt of the long-term network infrastructure, ajid may be sub ject to legal enforcement.^^ It is also conceivable that competition in the networking environment would cause customers to shy away from such dishonest domains. How ever, although some network-external mechanisms may alleviate the problem, they cannot provide an absolute solution. ^°TunneI costs caa be computed based on internal (in-cloud) accounting mechanisms. Alterna tively, they can be manuedly configured; or as a last resort, can even be set to zero for all tunnels. “ A similar problem exists outside of the computer domain: copyrights are respected not because it is hard to duplicate copyrighted material but mostly due to the perceived illegitimacy and the criminality of such acts. 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. There is however one significant difference between network clouds and other autonomous domains; network clouds may mis-represent their internal details unin tentionally (without malice). By definition, the cloud’s internal details are hidden firom the rest of the network; they may be hidden simply because one or more nodes do not support cost allocation, and have no mechanism to report cost information. It is reasonable to expect that as accounting mechanisms become widely available, this problem may be greatly alleviated. 71 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 7 Extensions to the one-pass m echanism In Chapter 5 we presented the one-péiss model as a mechanism for cost allocation, in the context of the basic network model. In Chapter 6 we introduced several extensions to that basic model; here, we focus on two of these extensions: multiple QoS levels, and multiple senders, and discuss their implications. However, we will not discuss the rest of the extensions since they were shown to be accommodated without changes to the original one-pass mechanism. 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7.1 M ultiple QoS levels The one-pciss mechanism advocates caxrying a single piece of information which reflects the unallocated (residual) cost from upstream. In Chapter 6 we argued that that extending the basic network model to allow multiple levels of QoS may be a local policy issue, and therefore should not be assumed uniform throughout the network. The local decision of how costs are split between the different QoS levels must be reflected in the accounting message. Having a single value is no longer enough; we must have a separate piece of information for each distinct QoS level. The same applies to the group membership information used by the one-pass mechanism to allocate costs; it must reflect the different QoS levels. The number of QoS levels for a given flow directly affects the scalabihty of the one-pass mechanism. This number depends on the service model; some service models, like controlled-delay [64] utilize only a few levels (< 10), while others, like guaranteed service [63] allow a continuous range with potentially infinite^ levels of QoS. Even when the number of QoS levels is high, it may still be possible, in some cases, to define the relationship between QoS and cost as a global function.^ This function can be applied at branching nodes, where the number of reserved QoS levels is quite small, since it is bounded by the number of outgoing reserved links. Another option is to divide a continuous QoS range into a few slots and to consider all the QoS requests within each slot as equivalent. 7.2 M ultiple senders In Section 6.3 we introduced the modified canonical form for shared channels. This canonical form uses the distinction between subscriber and non-subscriber receivers. This form provides a more general form of the ELSD scheme, which we caU Equal Link Split between Subscribers (ELSS). Implementation of the ELSS scheme with a ^The number of QoS levels is always bound by the number of individual receivers, since each receiver can only request one specific QoS level. "Consider the case where QoS levels depend on two parameters {Bandwidth, Delay bound}: one could define a global cost function between two ordered QoS levels, QoSi = Bi,Di, QoSn = Bg, Do as (B i+D il/fB o^D o). In each branching point, the reserved QoS level would determine the fraction of the residual cost that will be cdlocated to downstream over that branch. 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. V 2 V4 V6 Figure 7.1: Shared channel example one-pass mechanism requires that each node would know the number of subscribers to each shared channel. Unfortunately, this information is not trivial to obtain! In this section, we search for a reasonable mechanism capable of providing these numbers to local nodes in a relatively scalable manner. Figure 7.1 illustrates a shared channel example which will be used throughout this chapter. The general rule is that a receiver wiU be considered a subscriber of a shared lin!^ if the multicast path between that receiver and at least one of the sources it reserved traverses the shared link. Table 7.1 which records reservations made by each member (i.e., the list of senders each member reserves); considering this table, the determination whether a receiver is a subscriber of a shared link is not trivial, even for this relatively simple topology. Before we discuss mechanistic issues, we present in Table 7.1 the expected cost allocations resulting from applying the ELSS formula to this example. ^We use the term shared link to denote a section of a shared cheinnel over a specific link 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Link Sources V1..V5 U 2..U 4 V3..V4 V4..V5 Ü S-U 6 V6..V7 v e -v s total: Cost subscribed 1 2 3 5 7 11 13 42 mi 5i 0.25 1.75 3.67 5.67 m2 8 1 , 8 2 0.25 1 1.67 1.75 3.67 8.33 m3 0.25 3 1.67 1.75 3.67 10.33 m4 Si, 8 2 0.25 1 1.67 1.75 13 17.67 Table 7.1: Costs allocated, to members following the example 7.2.1 M echanistic observations In the presence of a single sender, obtaining the number of subscribers to a channel is achieved simply by summing the numbers of receivers along the tree. This simplic ity implies that the information can be provided to the cost allocation mechanism by either routing or reservation protocols.'* When multiple senders shaxe a channel, obtaining subscription information requires significantly higher overhead and algo rithmic complexity. This increased complexity may also imply that we should not expect either routing or reservation protocols to provide this functionality, at least not in the near future. If we search for a mechanism that will scale well with the growth in the number of receivers, we must look for a way to aggregate receiver subscription information. Counting the number of downstream receivers is insufficient; first, because in a shared channel environment the concept of upstream and downstream simply does not exist (see Section 6.3.1) and second, because merging receiver information at branch points merges receivers that may have different shared links to which they subscribe.® Let us introduce the term “ reservation scope ” to note the list of sources associ ated with a shared reservation [ 8]; in order to determine the number of subscribers to a shared link, we must have information about the reservation scope of individual receivers, and compare these scopes with the set of sources sharing the link. Ob viously, identical scopes can be aggregated: when several receivers have the same scope, they can be efficiently represented as a [scope,counter] pair. '* Hence the name one-pass, for the cost allocation downstream, does not tzdce into account an upstream pass of acquiring information about downstream receivers ®For example, in figure 7.1 and table 7.1, one can see that at merging node ug members reservations are merged even though no two of them subscribe to the same set of shared links. 75 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7.2.2 T he m odified one-pass m echanism In this section we describe a modified one-pass mechanism, which implements the ELSS scheme. The modified mechanism has similar characteristics to the original one: a single message is sent downstream, carrying residual cost information. Some of the cost is allocated locally, and some is allocated to downstream nodes. However, the modified version uses subscription, rather than downstream location information. The mechanism is split into two main phases: (1) acquiring information about the number of subscribers, and (2) performing one-pass cost allocation. 7.2.2.1 Pseudo code In tables 7.2 and 7.3 we provide a pseudo code description of the two phases of the algorithm. We assume that prior to the activation of the algorithm, control messages arrive and are promptly stored without processing. Each of the incoming and outgoing links maintains the information from these control messages as a list of scope records; each record contains a reservation scope, subscriber counter, and cost variable. 1) for each L{ € InLinks 2) for each m j € LocéilSubscribers_X,- 3) LS = createjscope(m y, 1, 0) 4) add_scope(X{.scope_/zst, L S) 5) for each Rk 6 ResvForwardOn_Zi,- 6) For each S R € Rk-scapeJist 7) SR’ = filter_scope(5R, Li) 8) add-SCope(X,-.scopeJisf, SR') 9) sen d (I,) Table 7.2: Algorithm: Phase I: obtaining subscription information Phase I: acquiring inform ation about subscribers Table 7.2 describes phase I: acquiring the number of subscribers. Line 1: main loop. Process each individual incoming shared link. 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Lines 2..4: generate the list of scopes for local members. Function cre- ate^copeQ creates a scope record for a specific member, containing its reser vation scope, counter = 1 and cost = 0. Function add^cope adds a new scope record to a scope list. However, if a record with the same scope already exists, the function merges the two (summing the counters of the new and existing records). Lines 5..8 : Collect all the scopes associated with reservations that are to be forwarded over link L{. For each, function filter.scope() removes from the scope record all the sources that do not traverse the incoming shared link.® The filtered scope is then added to L,’s list of scopes. Line 9: function sendQ sends out the list of scope records, over link Lj. 1) for each Lj 6 OutLinks 2) for each SR' 6 Li.scopeJist 3) SR'.cost = 0 4) for each L{ G InLinks 5) for each SR 6 Li.scopeJist 6) C = SR.cost / R.count 7) for each Lj 6 OutLink 8) for each SR' 6 match_scope(ijfc, SR) 9) SR'.cost += SR'.localxost C * SR'.count 10) for each Lj G OutLinks 11) send(£j) Table 7.3: Algorithm: Phase II: allocating costs to subscribers Phase H : one-pass cost allocation to subscribers Table 7.3 describes phase II: allocating costs to subscribers. Lines 1 .3 : Initialize the cost values for all outgoing links and their scopes. ®An arriving scope may include sources that use other incoming links. For example, the scope {[5i,x], [52, y], [54, z\} on a channel shared by 5o and S3 would be filtered, to become {[52, y]}). 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Lines 4..5: main loop. Process each individual incoming shared link. Line 6 : Compute the per-subscriber costs for each scope record. Lines 7..9: Function matchscopesQ returns all the scopes that are supersets of the input scope.^ Then, for each, the algorithm compute their residual costs. Lines 1 0..1 1: Send the aggregated costs to all outgoing links. The algorithm is greatly simplified because we consider local members as next hop nodes with one subscriber, connected to the local node by zero cost links.® Notice that since there may be multiple incoming shaxed links, and multiple outgoing shaxed links, processing is done in two phases; first, all incoming messages are processed and only then the outgoing messages are generated. This does not mean that these messages must be synchronized; we will discuss the synchronization issue later in this section. 7.2.2.2 E xam ple So far, in tables 7.2 and 7.3, we described the algorithm from the point of view of a single node. Here, in the example illustrated by figure 7.1, we view the global behavior of the algorithm over multiple nodes. As in the pseudo-code description, we separate the two aspects of the mechanism. First, we describe the messages that distribute information about the number of subscribers along the shared channel. Then, we describe the one-pass, cost allocation messages. Phase I: A cquiring subscription inform ation: Table 7.4 lists the first phase messages. As a result of these messages each node acquires the information needed for determining the number of subscribers to shared channels: given a shaxed incoming link, and a specific outgoing link, the number of subscribers for the shaxed outgoing link is computed by summing up the counters of all the reservation scopes that axe (1) associated with the ^Several scopes from outgoing links may have merged to create the scope on the incoming link. ®We allow ourselves to make this consideration since according to the ELSS scheme, the cost allocated to a local subscriber is identical to the one allocated to a downstream node with one subscriber connected by a zero cost link. In our prototype implementation (Chapter 8) this is actually the way local receivers communicate with RSVP. 7 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. message: From— »To Format (source list) : count V7 — * ■ ve (Si) : 1 (5i ,52): 1 (5’ i,53) : I vg — * ■ Vs (SuS2) : 1 Vs -»• Us ( 5 i ) : 1 (^ 1,^ 2) : 2 iSuSz) : 1 Ug — * ■ Vi (^i) : 4 Ug -* ■ U4 (^2) : 2 (5s) : 1 U4 —» U2 (5: 2) : 2 U4 Ua (^3) : 1 Table 7.4: Messages sent upstream following the example outgoing link, and (2) have at least one sender in common with the (incoming) shared channel. Notice that upstream from link (ug, ug) Si was filtered out of all the groups since it is no longer upstream on these shared links. Phase H: A llocating costs: Table 7.5 lists the messages of the second phase. These one-pass account ing messages carry residual costs. The cost allocated to each subscriber is computed as l/(num btr of subscribers). Notice that for the ug — » • ug message the cost incoming on scope (5i) is divided between three outgoing scopes, (5"i), (5 i , 52), and (5i , 53), since all three subscribe to (5i). As expected, we compaxe the results from the mechanism with the expected results (table 7.1), to discover that as anticipated they are the same. 7.2.3 Synchronization In the modified one-pass model, an outgoing cost allocation message may incorpo rate costs from several incoming shaxed channels.® In order for the mechanism to operate properly, all incoming messages must be processed, receiver subscription ^Consider the following example: an outgoing link with a scope of {5 i, So, 5a} incorporates two incoming link scopes of {5 i} «md {5a, 5a} 7 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. message: Format From— > -T o (source list) : cost Comments Vi -*• U s (Si) : 1 Only link cost U s -+ U 4 (5s) : 3 Only link cost U 2 U 4 (^2) : 2 Only link cost U 4 U s (5s) : 4.67 3 4-5/3 (^2 ) : 5.33 2 -F 5/3 *2 U s -»• U g (g% ) : 2 0.25 -f 7/4 (5 i ,52) :9.33 0.5 -t- 5.33 4- 2 * 7/4 {Si, S3 ) : 6.67 0.25 4- 4.67 4- 7/4 U g -+ Vj (5i) : 5.67 2 4-11/3 (5'i ,52) :8.33 9 .3 3 /2 -F 11/3 {Si, S3 ) : 10.33 6.67-F 11/3 U g Ug {Si,S2) : 17.67 9.33/2 -F 13 U % — y T T l\ 5.67 (^2) Vj — y IÏI2 8.33 (:9l,S2) Vj — » m3 10.33 U g — y T T I 4 17.67 (Si, ^ 2) Table 7.5: Messages sent downstream following the example information and costs must be calculated, and only then can outgoing messages be sent. Reservation protocols like RSVP use the same approach for their state setup protocol. RSVP receives and stores ail arriving messages, process them, and only then, sends periodic updates.^®. As a result, there is no need for any additional syn chronization mechanism when the modified one-pass mechanism is used over RSVP and similar mechanisms. 7.2.4 Evaluating th e size of control m essages In this section we investigate the scaling properties of the modified one-pass mecha nism by looking at the size of control messages generated by it. If the mechanism’s control messages axe piggybacked on RSVP, we must be concerned about their size, and their contribution to the overall size of RSVP messages. Each control message ^ “Expedited updates are sent when upon arrival of a new or updated state, however, in the stable state, RSVP performs only periodic refreshes. 8 0 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. (from phase I or II) contains a list of scope elements.The size of the exchanged messages depends on the number of distinct reservation scopes (over each any par ticular shaxed channel) and the size of each scope. Let us assume that bitmaps axe used to describe reservation scopes (i.e., a set bit declares the sender belongs to the scope). At first glance it may seem that the size of each scope can potentially be {S denotes the set of sources) and that shaxed chajinels can potentially have up to different reservation scopes. This may lead us to believe that the message size can be Od^l however, this is not the case. The number of distinct scopes for any given reservation, and the size of an individual scope, axe bounded by other considerations. Here, we present several common distribution models, and investigate the upper bound they impose over control messages size. First, we present a lemma: Lem m a 1 The number of reservation scopes over a shared link is always bound by the number of the different reservation scopes generated by subscribing nodes (nodes with subscribing receivers). This is straightforward, and can be learned from the definition of the mechanism itself: reservation scopes travel upstream (with reservation messages) toward the sources. Scopes may merge (if their scopes are identical), however a single scope can never split into several distinct ones. Therefore, the number of original scopes may decrease along the tree, but it can never increase. QED. G eneric Case In a generic case, we make no assumptions about reservation styles requested by receivers. We can define the following bound: T heorem 14 The number of reservation scopes over a shared link is always bound by the number of subscribing receivers. ^^The messages that flow upstream and provide subscription information as well as the mes sages that flow downstream and provide cost allocation information, contain list of records, each representing a different reservation scope. 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. By definition of the algorithm, each receiver can only generate a single scope on each local interface (link). Because multicast maintains a tree format, reservations made on each local interface never merge, and therefore, each receiver may only contribute one scope for each shared link. Combining this with our lemma, proves that he number of scopes on any shared link is bound by the number of reserving receivers. QED. We assume that routing does not discriminate between sources, therefore, all the sources on the same node are forwarded along the same path. Taking this in mind, there is no need to include per-sender state in the reservation scope; per-node state is enough. Let N$ denote the set of nodes with sources, and R denote the set of receivers; The size of an individual scope is bound by (9(|Ws|), and therefore, the overall size of control messages is bound by 0(|i2| * |iVg|). W ild c a rd F ilter Theorem 15 The number of reservation scopes for a WildCard Filter reser vation style is bound by the number of nodes with receivers located on them. In the Wildcard Filter style, receivers residing on the same node must have the exact same reservation scope. This means that a node with any number of receivers, can only create one scope on any given incoming link. Combining this result with the lemma proves that the number of reservation scopes on any shared link is limited by the number of nodes with reserving receivers. QED. Let Nr denotes the set of nodes with receivers, we can see that the size of control messages is bound by 0(|7Vh| * |-^s|)- If we assume this is a symmetric audio conference, where receivers are also potential sources, and vise versa, then the upper bound becomes: OdTVRp). W ild c a rd F ilter, H ierarchical m ulticast distributions Autonomous systems (AS) in hierarchical inter-networks hide their internal topology firom the higher level routing protocol, and therefore, may appear the 82 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. rest of the network as having the same routing characteristics as single nodes. We Cein therefore assume that theorem 15 applies to AS’s as well, and that the number of reservation scopes on a shaxed link between AS’s is bound by the number of subscribing AS’s. Cleaxly, the same hierarchical argument applies to senders. Let ASr and ASs denote the set of autonomous systems with receives, and senders, respectively, we cam see that the size of control messages is bound by 0(|i45fl| * |AS'g|), or for an audio conference: 0(|A 5r|)^). If we assume L level hierarchy, this is roughly equal to 0(\R \^) which is bound by 0(|i2|) V L > 2. W ild c a rd F ilter over shared trees m ulticast d istrib u tio n T heorem 16 The number of reservation scopes for a WildCard Filter reser vation style over a shared multicast tree is bound by one. Since all the receivers reserve all the sources, and ail sources share the same tree, there can only be one scope, which is the set of all sources sharing the tree. QED. With only one possible scope, the scope can actually be implied, and therefore, redundant, of size 0(1). This conclusion should not come as a surprise because this case is actually the equivalent of the original, non-shared chamiel case. We have not investigated the average case in depth, however we believe it is reasonable to expect that on average, control messages would have significantly lower sizes than these upper bounds; in large networks we expect that neighboring nodes or autonomous system (in the case of hierarchical multicast routing) will have identical or very similar scopes. The modified one-pass mechanism provides an axiomatically sound cost alloca tion model, however, it has significant scaling drawbacks. In the next section, we describe an ad-hoc mechanism which trades some axiomatic soundness for better scaling properties. 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 7.2.5 Per-source allocation o f shared channel costs A possible approach could be to split the cost of a shared channel locally on each link between the sharing sources. First, the cost of a shared link is split between the sources, and then the per-source cost is allocated to receivers. It is straightforward to implement this approach by using the previously defined one-paas mechanism (model 1 or 2) with some slight modifications: (1) Control messages carry per-source information (i.e., the upstream message carry a number of receivers downstream for each source, and the downstream one carry the residual cost allocated of each source). (2) Local costs of shared channels are split locally, for each source, and are added to its residual cost. (3) the cost allocated to a receiver of a shared channel is the sum of the per-source costs allocated to that receiver. This approach has similar scaling properties to RSVP: the size of the policy information is |5| (number of sources), which is of the same order of magnitude as the RSVP reservation scope object. 7.2.6 D iscussion In Sections 6.3 and 7.2 we describe the ELSS mechanism as an axiomatically sound approach for supporting shared channel cost allocation. Unfortunately, it was shown to have less than desirable scaling properties. We have seen that the modified one- pass algorithm scales very well only when WF shared channels are deployed over shared trees.clearly, in this case the modified one-pass mechanism is not needed, and the original one-peiss mechanism would do well. With the absence of shared trees, RSVP itself does not scale well since it uses a scope object that is bound only by the number of sources 0 (|5 |). However, the modified one-pass mechanism scales even worse at 0 (|5 p ). In the hierarchical case, RSVP could be made to scale better, and so would the modified one-pass mechanism, however, the latter would still scale significantly worse than the former. We see the modified one-pass mechanism as a viable approach for small conferences for which scaling is not an important issue, and where the distributive notions of cost allocation are important. However, large conferences may be better served by some ad-hoc mechanism which ^ “When using the modified one-pass mechanism for arbitrary shared channels, which are not of WF type, a shared tree provides no significant advantages over using non shared trees. 84 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. has better scaling properties, even at the expense of some axiomatic soundness. We offered an example of one such possible ad-hoc mechanism for performing per-source cost allocation, in Section 7.2.5. 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 8 D esign and prototype im plem entation The previous chapters described the theoretical eispects of cost allocation and pos sible mechanisms to implement them. We have observed that the ELSD scheme emerged as the most attractive scheme, and that it could be implemented by one- pass mechanisms. Here, we taJce the next step of applying our finding to an actual working system. We had two bzisic choices: one was to design a specific implemen tation tailored for one particular cost allocation scheme, which could be simple and minimalistic or, the other, which we finally adopted, w éis to design a mechanism that would be able to accommodate for greater flexibility in policies. Our design attaches a generic, modular “box”, called LPM (for Local Policy Modules), to reservation es tablishment protocols. The LPM box supports a wide range of policies, and allows inter-operability of multiple cost allocation, accounting and access control policies in one generic policy-based admission control mechanism. In this chapter we de scribe the building blocks of the LPM architecture, and describe the way by which these building blocks can be configured to implement the one-pass mechanism and the ELSD cost allocation formula. We also discuss some of the issues involved in adapting the generic architecture to real world reservation protocols like RSVP. We conclude, as a proof of concept, with a description of our prototype implementation. 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.1 Overview în many respects, the design of a prototype implementation completes the circle of our work. The first inspiration and motivation to investigate the issue of cost allocation over multicast trees originated with the RSVP project [ 8].^ While our work is not specific to RSVP, it was only natural that RSVP was chosen éis the network environment for our prototype implementation. Reservation protocols, by design, provide preferential treatment for reserved traf fic over other traffic types. In an increasingly commercial and competitive network ing environment it is reasonable to expect that such protocols would be accompanied by policy control mechanisms. The term policy control is quite broad; it ranges from simple access approval, all the way to sophisticated accounting and debiting mecha nisms. Unless we believe in a single omnipotent and omniscience access control and accounting policy, reservation protocols like RSVP must be able to accommodate multiple, dynamic, and independent policies. Instead of defining specific policies, we chose to define only the basic interface between policy control and reservation protocols. In this chapter we describe the Local Policy Modules (LPM) architecture which defines a set of building blocks for access control and accounting architecture in RSVP. The architecture defines the range of policies that m ay be supported, but leaves the specific policies to local LPM configurations.^ It is commonly agreed upon in the literature that reservation protocols must consult with a resource (ca pacity) based admission component before admitting a new reservation. We extend this model, adding the need to consult a policy-based admission component as well. RSVP’s decision to accept or reject a reservation must be based on the overall results from both admission components. The LPM architecture is based on three fundamental principles which are re flected by its name: Local reflects the the locality of policies. Policy reflects the discussion of supported policies, and M odule reflects the functional separation of policies from reservation establishment protocols. The first principle is mandated by ^RSVP is developed as a collaborative effort. Development of an RSVP reference implementa tion was carried out at the University of Southern California/Information Sciences Institute, the author being one of the developers. -The LPM architecture does not advocate specific policies, however, in this chapter we describe the details of MultiCost, which implements the one-pass, model 2 cost allocation scheme. 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. our social reality: autonomous systems tend to define and implement their own local policies; we expect policy enforcement mechanisms to provide local administrators with the capability to define usage policies and enforce them locally. The second principle involves the model of supported policies. Clearly, the LPM architecture should not have worst scaling properties than RSVP. This leads us to the bilateral agreement model, discussed in the next section, which is shown to have constant scaling properties with respect to the number of receivers.^ Last, the third prin ciple calls for functional separation between policy enforcement and RSVP. Usage policies can be diverse, complex, dynamic and sometimes even arbitrary in nature. The dynamic evolution of usage policies cannot be served well when policies are tied to rigid functional specifications of network technology (e.g., the RSVP functional specification [8]). We therefore believe that usage policies should be left outside of the RSVP’s specifications, and be defined by a separate “box”. In Section 8.2, we describe the basic Local Policy Modules (LPM) model. Sec tion 8.3 provides a simple access control scenario. Section 8.4 provides a general description of the RSVP/LPM interface. Section 8.5 discusses RSVP related issues, and Section 8.6 provides a peek into some details of the LPM prototype imple mentation. Diverting from the generality of the LPM architecture, the last section (Section 8.7) describe the specific details of MultiCost which implements the one-pass mechanism, model 2 (the ELSD cost allocation scheme). 8.2 The local policy m odules (LPM ) m odel In this section, we discuss the three fundamentals of the LPM architecture, which correspond to the initials LPM: the policy model, locality of policies, and the func tional separation of policies from RSVP.'* ^Having global information or agreements about individual receivers, scales linearly, which is clearly worse than RSVP’ s scaling properties. The LPM architecture does not rule out such ap proach, although, it will only scale well when a non-global model, like the bilateral agreement model, is used. We discuss them according to their natural order, rather than the order of initials in the name LPM. 88 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.2.1 LPM ; policy The LPM architecture is capable of accommodating a broader range of policies, since it enforces very little if any limitations on them.® However, we limit ourselves only to policies that scale well, and which, when configured into the LPM, are guaranteed not to have inferior scaling properties than RSVP itself.® One cleiss of policies that scale well is based on bilateral agreements. We use the bilateral agreement model as an example of a viable approach. The bilateral model is described in greater details in [60]; there, we present various additional accounting mechanisms that may be supported by this model. The bilateral agreements model assumes that autonomous systems (AS), (e.g., network service providers) contract with their closest point of contact (e.g., neighboring AS or local customers) to establish ground rules and arrangements for access control and accounting. Consider two network providers A and B establishing a monthly agreement for traffic exchange; a simple agreement could grant provider A’ s traffic, access to 5 ’s network resources (and vice versa). Bilateral agreements can be characterized as generic and long-term, which means that they are expected to proceed and outlive specific reservations. In this work, we do not discuss mechanisms by which bilateral agreements are reached, simply because such mechanisms axe considered to be outside the scope of the network infrastructure.^ Once bilateral agreements axe established, their contents (rules and regulations) must be converted to a language understood by the network policy enforcement mechanism (i.e., LPM). It is straightforward to show that the bilateral model has similar scaling properties to RSVP; assuming that bilateral agreements are mainly between neighboring entities, the number of agreements and the size of information maintained by each node remains constant with respect to the number of receivers. ®The LPM design allows even the most centric policies; consider the case where all access decision for the entire network are made by a single server. Even such unthinkable policy can be implemented by configuring all the LPM modules to query this single server for each reservation request they receive. ®Any model that requires nodes to maintain global information or reach agreements about individual receivers, would scale linearly, with the number of receivers, which is worse than RSVP. ' Bilateral agreements may be reached through legally drafted contracts, phone conversations or other types of human contact between legitimate representatives of the parties to the agreements. 8 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Reservation protocols, serve as setup mechcinisms for establishing reservation state across the network; the same mechanisms could be used for establishing policy control state along reserved paths. The RSVP functional specification [8] defines a special object-type called “POLICYJDATA”, which contains policy related infor mation (e.g., it may contain credentials that identify the “owner” of a reservation). Policy data objects are optional, opaque to RSVP, and are transported piggybacked in regular RSVP messages (e.g., Resv, Path, etc.). If present, these objects are received and processed by policy nodes.® In order to apply specific bilateral agree ments, a policy node must first identify the set of bilateral agreements that are associated with each specific reservation or flow. This classification may be implicit, based on general reservation information (like IP address, reservation type and size, etc.), but may also be explicit. Policy nodes can consider the contents of policy data objects, the appropriate bilateral agreements, and other local considerations, in or der to reach a policy decision. Policy nodes may also be authorized to manipulate and rewrite the contents of policy data objects before forwarding them. 8.2.2 LPM: local The success and scalability of the current internet technology could be partially attributed to the distributed and local manner by which it is managed. In many cases (e.g., DNS®), responsibility is delegated hierarchically, and control is left to the administrators of autonomous systems (AS). The LPM architecture respects this social reality by allowing the local administrators of resources to locally define and configure the policies that govern their usage. RSVP’s setup mechanism uses hop-by hop, soft state, delivery. It collects information from all incoming messages, stores it, and later, generates output messages. Local policies affect the state maintained ®The term “policy nodes” describes these nodes that enforce policies, as opposed to other RSVP nodes that may process reservations but do not concern themselves with any sort of access control policies. For example, the common case is where boundary nodes serve as policy nodes, while internal nodes lack policy enforcement capabilities. ^Domain Names are assigned hierarchically. An autonomous system is delegated a domain, and is free to allocated it internally as it wishes, including re-delegating responsibility over sub-domains to smaller size AS’ s. [46] 9 0 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. by the LPM box; they determine the contents of outgoing messages/” and the status of reservations. 8.2.3 LPM: m odule Network technology often complies with established oflScial or de-facto standards, and can generally be characterized as highly stable and rigid. In contrast, usage policies axe often set according to timely administrative needs; they tend to be diverse, complex, dynamic and sometimes even arbitrary in nature. The different characteristics of the network technology and usage policies suggest that they must be functionally separate, to support both the stability of the network technology, as well as the dynamic and diverse nature of usage policies. This functional separation is achieved by defining the LPM as a “box” separate from RSVP. The policies governing the box and the state maintained by the LPM box are hidden from RSVP. This separation could not be complete; the two boxes interact through a well defined, standard interface, (described in Section 8.4). 8.3 Sam ple scenario: sim ple access control We start, in this section, by outlining a simple access control scenario to motivate and explain the role of the LPM architecture. Our sample scenario is baaed on realistic portrayal of connectivity between internet service providers (ISPs). We maintain this realistic depiction by using actual ISP names (as opposed to abstract names) however, the actual names carry no functional significance. We consider this scenario as a basis on which more complicated access control mechanisms, like MultiCost, can be constructed (MultiCost is described in Section 8.7). As its name implies, simple access control is a very basic, minimal form of access control. In this scenario, local LPM modules classify a reservation and identify the usage group to which it belongs. Once the usage group is identified, the decision whether to accept or reject a reservation is based on the contents of the bilateral agreement associated with that usage group. Consider the following network sce nario: a single receiver from ISI and two from MIT listen to a PARC seminar. For ^°See credential translation tables from Section 8.3 91 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. BARRfict M C I N e t M C l N e C Figure 8.1: Simple access control simplicity, let us limit ourselves to a receiver based access control scenario. The bilateral agreements between each two neighboring providers (e.g., Rl, R2 with ISI, ISI with LosNettos,... BARRNet with PARC) are simple: the first provider obtains permission to make reservations over the second provider’s network. The notation PD{cr, uid) represents a policy data object of type “cr” (credential) verifying that the flow belongs to uid. Credentials can be hierarchical, and may be rewritten on a hop by hop basis according to a locally configured conversion table. Figure 8.1 illustrates a reservation scenario, where reservations from Rl, R2, R3 propagate hop-by-hop toward Si, carrying policy data objects. Further more, we assume that policy is provider-based, and therefore is enforced only at border nodes {B ,D ,G ,I,K ,M ). Consider the MCINet cloud, a reservation request arrives from node K to cloud entry node J, carrying a policy object PD{cr, N earN ti). Node J accepts the reservation since the local policy allows NearNet traffic. Another reser vation from node N arrives to node J carrying a policy object PD{cr, Sprint). This reservation is rejected because MCI does not have a bilateral agreement with Sprint to allow its traffic into MCINet. Border nodes may also be authorized to rewrite 9 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. policy objects. In this scenario, credentials are hierarchical: they are rewritten at cloud exit nodes, in order to identify the outgoing traffic as belonging to the cloud (or service provider). The MCI cloud is interesting. E receives the following pol icy data objects: F— +E: PD{cr, LosNettos) and J — •■ E : PD{cr, NearNet). E is not a border/policy node, and has no authority to merge or rewrite these credentizds, therefore, it concatenates the two objects and send the result, PD{cr, LosNettos) 4- PD{cr, NearNet) to D. Let us further assume that D is configured with the follow ing conversion table: PD{cr, LosNettos) = > PD{cr,M CI) PD{cr, NearNet) ==^ PD{cr, M CI) D’s LPM converts, merges and rewrites these policy objects as PD {cr,M CI) and forwards the reservation to C. If instead, the conversion table was PD{cr, LosNettos) ==> PD{cr,M CI\) PD{cr, NearNet) = > PD{cr,M Cl2 ) then D’s LPM would forward PD{cr,M CIi) + P D {cr,M C l2 ) to C instead. 8.4 The L PM interface This section outlines the basics of the LPM interface. The principles that moti vated this architecture were the need (1) to support multiple access control schemes concurrently, (2) to allow local configuration and dynamic binding of access con trol schemes, and (3) to achieve functional separation between LPM and reservation protocols modules (i.e., minimize the interaction between the two to a well defined interface, while disallowing any shared state between them). Figure 8.2 illustrates the components and their functional relationship. The LPM architecture extends the scope of the RSVP’s admission control to consider policy-based admission; a reservation must be approved both physically, by tradi tional congestion based admission control, and administratively, by local policy. The RSVP-LPM interface is made as a set of services (API style) that are provided by 9 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In/O utgoing objects R eservatioii status S tatus RSVP LPM Approval Capacity-based Adm . Control Figure 8.2: The modular context of access control the LPM box, to RSVP; these services majiipulate POLICYJDATA objects, report policy status, and perform other policy related services. 8.4.1 POLICY_DATA objects: sem antics and form at Policy data objects axe transported piggybacked on RSVP messages, and carry ac cess control setup information. The information they carry is associated with RSVP flows represented by RSVP filter specs. The policy resolution is determined by RSVP’s handhng of these objects; subject to RSVP’s support, it can be carried out per-flow, per flow-aggregate, per session and even per session group.Policy data objects can potentially be carried by any RSVP message, (e.g.. Path, Resv, ResvErr, etc.), although, they may not be needed for some message types (e.g., PathTear). Figure 8.3 illustrates the multi-layered format of policy data objects. The basic building block axe policy attributes. Policy attributes represent specific policies (e.g., ELSD). Policy nodes pack all the policy attributes of the same flow into one policy element. This packing allows the LPM to distinguish and between policy attributes that originate from different previous or next hop neighbors. The ^^with the absence of RSVP filter specs the contents of a policy data objects are associated with all the fiows of the session. We imagine that some access control mechanism may find session objects to be sufiScient for their needs, while others may require the full power of per-flow objects. 9 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P O l. lC Y l> VT A o b jc v t I ' u l i , 1 I I , I I I * I I I Z * I ' l i l i t \ I U n u T i ( V nu \ F O I K > M M \ uhj.O Figure 8.3: POLICY_DATA objects, format, integrity and handling integrity of policy elements (and their internal attributes) is guaranteed by a preced ing integrity object.As the last level of encapsulation, policy data objects include a collection of policy elements received from various previous/next hop neighbors and a list of flows associated with this policy data object. The concatenation of multiple policy element objects arriving from multiple pre vious/next hops may cause policy data objects to become quite large. (Exceeding the size of the path MTU by orders of magnitude.) Semantic fragmentation provides a reasonably good solution for fragmenting policy data objects; since concatenation of objects produces large policy data objects, we see no reason why the original, self contained objects could not be forwarded individually. For more details about semantic fragmentation of policy data objects see [33]. 8.4.2 L PM services Figure 8.4 illustrates the flow of data and control messages between policy nodes and within each node. This flow of messages is supported by a set of services provided to RSVP by the LPM. These services can be divided into four categories: input, output. ^'This integrity is calculated over the following policy element object by the previous/next hop policy node. It guarantees that the contents of the policy element object originated from that hop and was not tampered with. For more details see [3, 42]. 95 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Policy Node A Higher layers I B 3 i M I I « m m Hetwoik/Transport ('«introl HatkcLs Data Packets Policy Node B Higher layers 6 3 LPwEicommoiijayet ■■■■ Network/Transport Figure 8.4: LPM and RSVP: message flow outline status and other support services. RSVP messages with embedded POLICYJ3ATA objects trigger the LPM mput service while outgoing messages require that the LPM output service build outgoing POLICY-DATA objects. The LPM status service is used to verify the status of new or existing reservations. Léist, there is always a need for a few other support services. In this section we describe the four service categories, and provide pseudo system call formats, using RSVP data structures. Let us start with the last category first, since some support services must take place before any other services. 8.4.2.1 Services Overview Here, we discuss generic issues that are common to all the LPM services. R eporting th e success of LPM services All the LPM calls report success/failure status. This report is comprised of three components: a generic return code of the 1pm function, that reports the general success of the call, a global variable Ipm .eTm o that reports specific, higher resolution reason code (similar to the ermo in Unix), and a global variable Ipm^eflgs, for flags that can be set by some of the calls. ^^The parameters provided with these pseudo calls are merely provided to illustrate the service. They should not be considered an interface specification. 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Flow handles (fh) The LPM maintains access control state per flow. This state is complementary to the RSVP state, and both are semantically attached by flow handles. RSVP obtains flow handles by calling lpm^open(), once on the first arrival of a POLICYJDATA object for each session or flow. RSVP stores the flow handle in the flow’s data structures, for future 1pm calls. A ssociating source and receiver objects The access status of a reservation may depend on policy data objects that orig inate from sources, receivers or both. For instance, a lecture can be sponsored by a source which would provide the necessary credentials. If the LPM archi tecture is to support source based policies, it must have the abihty to associate source objects with reservation state. Some associations are trivial (e.g., fixed filter (FF) reservation style) but some are more complicated (e.g., WildCard Filter (WF) reservations). This association depends on RSVP’s reservation styles, and therefore should be left at the responsibility of RSVP. If multiple sources are associated with a single reservation, then a list of all the flow han dles associated with these sources must be passed on to the LPM. In the LPM call format, the list takes the form of a pair of parameters, fh.num and fn-vec) describing the number and the array of flow handles. 8.4.2.2 S u p p o rt services lpm_config (void) This service is called only once, in the initialization phase of RSVP; it initializes the LPM and causes it to read its local configuration files. Ipm -open (fh) For each new flow, when its first POLICYJDATA object arrives, RSVP calls the Ipm^open service. As a result, the LPM builds internal control blocks and returns a flow handle. This flow handle should be stored by RSVP for future reference to other LPM services. lpm_close (fh) 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. When RSVP disposes of a flow or a session, it should notify the LPM that the fh allocated to the flow or session is no longer needed. Upon this notification, the LPM finishes its accounting for the reservation associated with fh (final debits/credits), deletes all the state associated with this it, and releases the fh . Ipixi-prune (fh_num, fh_vec, vif, hop, m type) When RSVP prunes a branch of the reservation tree, it must notify the LPM to purge all the state associated with that branch. 8.4.2.3 Processing incom ing messages RSVP calls the LPM to process each POLICYJDATA object it receives. The LPM processes and the object, stores the results, and returns a status code to RSVP. This status code reports on the success or failure of the object processing, but does not reflect the acceptance of the reservation. The status of a reservation must be checked separately (see Section S.4.2.5 for more details). Ip m Jn (fh_num, fh_vec, vif, hop, m type, polp, ttd ) Parameter vif describes the input virtual interface^'* from which the RSVP message was received, hop describes the node that sent the RSVP message (previous or next hop), and mtype describes the type (and implicitly, the di rection) of the RSVP message (i.e.. Path, Resv etc.). Parameter polp is a pointer to incoming policy data object. From these parameters, the LPM can figure out some topology information (e.g., the origin of the POLICYJDATA object) and some RSVP context (e.g., the message type and the list of flow handles). ^■*T he term Virtual Interface (vif) is borrowed from DVMRP[67] terminology, although, for LPM purposes it may be any protocol independent integer index that RSVP uses to associates] with specific interfaces. 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.4.2.4 Processing outgoing m essages When RSVP is ready to generates an outgoing message, queries the LPM to check for outgoing policy data objects. If appropriate, the LPM assembles outgoing policy data objects and hands them to RSVP for placing inside the outgoing message. lpm_out (fh_num, fh_vec, vif, hop, m type, polp) The parameters here are similar to those for IpmJn. A successful cédl places a pointer to the outgoing POLICYJDATA object in polp. Notice that although the output process is performed separately for each outgoing RSVP message (on separate virtual interfaces or next hops), it is required to remain consistent in the face of intermediate LPM state changes. 5.4.2.5 R eservation statu s The general concept of access control assumes that all admitted reservations are conditional, in a sense that state or network changes may reverse the admission decision. Consider the case where access control is based on availability of quota; an admitted reservation may exhaust its quota^® and be canceled despite being fully admitted previously. Policy-based admission control must verify the status of ail previously admitted reservations both periodically and as a response to changes in policy related state. Checking the status of an existing reservation is done by calling: Ipm jstatus (fh_session, fh_num, fh_vec, vif, c u r.tim e , phy_resvJiandle, phy_resv_flwspec, ind) Status is checked individually for each outgoing (reserved) link. Parameter fh-session specifies the flow handle associated with the session, phyjresvJiandle ^®RSVP reservations are not made for a finite length of time; the lack of knowledge about the length of a reservation precludes from determining the total usage of the reservation ahead of time. Instead, admission must be based on temporal availability of quota for some finite period of time; re-examination of the admission decision must take place (and possibly fail) when reservations extends beyond their initial admittance period. ^^Re-examination of existing reservations as a result of policy state changes may be limited in scope only to those reservations that may be affected. 99 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. identifies the physical reservation (e.g., ISPS, etc.), ajid phy.resv-flwspec de scribes the current, merged FlowSpec of the reservation. The ind parameter allows optimization of status checks. When status checks involve calculations over multiple outgoing interfaces, they can be optimized to be performed once, for all interfaces, before individual per-interface status is reported. 8.5 R SV P related issues In this section we discuss a few of the higher level issues that emerge from the interaction between reservation protocols (like RSVP) and the LPM architecture. 8.5.1 State m aintenance LPM state must remain consistent with the corresponding RSVP state. State is created when POLICYJDATA objects axe passed to the LPM; it may be updated or removed through several possible mechanisms that correspond to RSVP’s state management mechanisms: T im eout: When new POLICYJDATA objects cease to arrive (as a result of either change of policy or fragmentation loss) the locally stored state begins to age. Each POLICY_ELEMENT/FILTER_SPEC peiir is subject to a timer, and when the timer goes off, the state should be deleted. The timer mechanism should be similar to that of RSVP and both should remained synchronized in the follow ing way: each time RSVP hands over a policy object to the LPM {IpmJuQ) it provides the LPM with time-to-die value {current-timer -h time-to-live) . Each time RSVP verifies the status of a reservation {lpm^tatus{)), it provides the current timer value, forcing all pieces of information with an earlier timeout value to be purged. ^'The LPM ^TATFJIECALC: flag can be set when the first vif is checked, indicating that cal culation is to be performed. The flag can be reset for the other interfaces, indicating only reporting is needed. We would like to stress that being an optimization there should be no conceptual harm in recalculating status parameters, for each outgoing interface. 100 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Teardown From a network security standpoint, creating new policy state requires the sim ilar integrity protection as tearing it down. We propose a very simple mecha nism for tearing down state: the state created by sending POLICY .ELEMENT P ti is tom down by sending — Pe,- (the same object marked as teardown). In this case, the LPM would locate the original state, compare it with the teardown object, if a match is found, tear it down. We define each POL ICY -ELEMENT as a pair of two CTypes, thus effectively splitting the CType range of POLICY .ELEMENT objects in two. Given a POLICY-ELEMENT i, Pei represents an updated state, while Pe,+i represents teardown state of CType i (— Pe,-). P runing When the shape of the reserved tree changes due to routing updates or RSVP teardown messages, RSVP purges the state of the pruned link, and must also call lpm-prune() to purge the corresponding LPM state. Closing: The call Ipm-close(fh) purges all the state associated with the handle fh. Clos ing a flow handle is done when RSVP no longer maintains any state associated with that flow (a sender quits, the session is over, etc.). 8.5.2 D efault handling o f policy data ob jects We do not expect (or desire) that every RSVP node will be capable of processing all types of policy data objects. Consider the case where policies are hierarchical, allowing different policies to be enforced intra-net and inter-net. In this case, inter net policies inside POLICY-DATA objects would pass through internal nodes that will not be able to recognize them. It is essential that RSVP define default handling for cases where it receives unrecognized objects. The general concept is that RSVP play the role of a repeater (or a tunnel) by forwarding the unrecognized, received objects without modification. To maintain connectivity along the distribution path, this default behavior should be part of any RSVP implementation along that path. 101 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Implementation details are a part of the internal LPM architecture, described in Section 8.6. 8.5.3 N ew R S V P m essage: reservation R eport The basic building blocks of access control and accounting must be bi-directional in order to allow both source and receiver based policy data objects and both adver tising and feedback. Which RSVP messages should encapsulate these upstream and downstream objects? The choice for upstream message is natural: the reservation message. The downstream message, however, is more problematic: path messages flow downstream, but axe routed according to the m ulticast group membership, and therefore cannot guarantee accurate delivery.** The inherent lack of accuracy makes Path messages less likely to be used for access control, and especially for accounting. We propose a new RSVP message type: Reservation Report (Rept). Reservation Report messages are sent unicast, downstream, according to the Next_Hop object carried by Resv messages, although Reservation Report messages follow the reserved tree, their unicast delivery allows delivery only over the appropriate branches of the tree, and even to a single, specific receiver at the leaf. Although we propose this new message type for supporting the LPM architecture, it may prove useful for other, more general functions of the RSVP protocol.** 8 .5.3.1 Security issues The RSVP security mechanism proposed in [3] relies on hop-by-hop authentication. This form of authentication creates a chain of trust that is only as strong cis its weakest element (in our case, the weakest router). As long as we believe that all RSVP nodes are policy nodes as well, then RSVP security is sufficient for the entire RSVP message, including POLICYJDATA objects. This however is not the case ^®Consider the case of multipoint links or network clouds (e.g., ATM): a single copy of a Path message may be delivered to an unknown number of next hops, therefore, accurate delivery to one and only one specific next hop cannot be guaranteed. ^ ® A reservation may have trigger different forms of responses: A negative response (ResvErr), a positive response (ack), and a more advanced form of a Reservation Report, like the one proposed here. An integrated approach may incorporate all three responses, utilizing the same message type, while leaving room for future uses. 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. when policy is only enforced at boundary nodes. If policies are only enforced at cloud entry and exit points, then RSVP’s security is insufficient to protect policy objects, since from a policy enforcement perspective, the in-cloud nodes are unse cured. We propose a “policy data tunneling” approach, where the logical policy topology is discovered automatically, and security is enforced over the logical topol ogy. Policy objects created at border routers are encapsulated in a security envelope using RSVP’s integrity object (see Section 8.4.1). This envelop is forwarded as-is over the cloud; it is only removed by the cloud boundary (exit) node. 8.6 LPM internals This section describes the latest internal design of the LPM, as it exists in our prototype implementation. In previous sections we described the interface between RSVP and the LPM, however, here we discuss our design approach to LPM internal issues. 8.6.1 LPM configurations LPM configuration may be expressed as a simple, locally defined, configuration file or even through a configuration language. Some configuration may be general, for all handlers, while others may be type/handler specific, (e.g., a specific handler’s rewrite conversion table for policy data objects). 8.6.2 T he LPM layered D esign The internal format of POLICYJDATA objects is PType specific, allowing up to 65535 independent types. Our design allow each specific PType to be handled by a separate handler, and allow such handlers to be added and configured independently. Clearly, handlers axe allowed to handler more than one PTypes. The LPM is divided into two layers: a PType specific layer and a common layer (Figure 8.5). The PType specific layer provides a set of locally configured independent handlers, one for each PType supported by the local node. The common layer provides the glue between RSVP and the PType specific layer by multiplexing RSVP’s 1pm calls into individual, PType specific calls. 103 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. RSVP ISQH32ZE2 Common Layer IpmJnO Incoming RSVP RESV masMago / ■ ■ ■ HaodleiO Handlerl Handler! Handlers Handlerd Figure 8.5: Disassembly of an incoming Resv message with POLICYJDATA objects On input, the common layer disassembles the incoming POLICYJDATA object, dispatches the internal objects to their PType specific handlers, and aggregates the return code status (Figure 8.5). On output, it collects the internal objects from all active handlers, and assembles them into a single POLICYJDATA object (Figure 8.6). On status queries, the common layer queries all the active handlers, and combines their individual status responses into a single status result. We use the following rule: a reservation is approved by the common layer, if there is at least one handler that approves it, and none other rejects it. PType specific handlers can accept, reject or be neutral in their responses. 8.6.3 Interaction b etw een handlers It is reasonable to assume that independent PTypes may require some interaction between their handlers. Consider the case where policy object type-1 is a credential type (defines a user identity) and a type-2 is an accounting type (determines cost), a possible interaction could be to let type-2 determine the cost, and let type-1 perform ■°A policy data object that determines cost is a good example for a neutral handler. It provide information about how much the Sow costs, but does not perform actual debiting. 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Outgoing RSVP RESV messago lp m .o u iO Common Layer IpmjoutQ HandlciO ■ ■ Handlerl Handler! Handler) Handler4 Figure 8.6: Assembly of POLICY_DATA objects for an outgoing Resv message the actual debiting according to the user identity. Such interaction has two basic re quirements: order dependency and export capability. Order dependency is required because type-2 must calculate the cost before type-1. Export capability is needed to allow type-2 to export the calculation results to type-1. Our implementation allows the ordering or handlers to be expressed as part of local LPM configuration. It also provides internal support for function calls between independent handlers (in order to obtain exported state). Consider the case where type-3 and type-4 also perform accounting. The pro posed architecture is flexible enough to allow local configuration to select the handler that determines the debited cost: type-2, type-3 or type-4. 8.6.4 D efault handling o f policy data ob jects In [33] we define the default handling of unrecognized POLICYJ3ATA objects. If an RSVP node is LPM capable, it may be more beneficial for the LPM to take that burden off from RSVP and perform it itself. We propose the use of CType 0 for default handling. In a policy node, only unrecognized objects would be handled by handler PType 0. In a non-policy node, all objects are unrecognized, and therefore should all are handled as PType 0, regardless of their actual PType. PType 0 is regarded as a reserved type. 1 0 5 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.7 M ultiCost: m ulticast cost allocation Previously, in this chapter, we described the building blocks of the LPM architecture; here, we describe how these building blocks can be formed to implement the ELSD accounting scheme (using the one-pass, model 2 mechanism from Section 5.3). We name this design and prototype implementation, “MultiCost” (or MCost). As a first step, we describe a simple accounting scenario, which lays the foundation for describing the detailed design of MultiCost. 8.7.1 Sim ple debiting In this simple debiting scenario, the information needed to perform debiting is as sumed to be available locally. We have already seen in Section 8.3 that simple access control provides information about the usage groups to which reservations belong. After we know who should be debited, we are left with two questions: how m uch should be debited for a reservation and what debiting m echanism should be used, if any.^^ Here, we assume that bilateral agreements are reached between us age groups and providers before any reservations take place. These agreements may pre-purchase network capacity, set local accounts, and agree on applicable debiting rules. The role of the accounting mechanism is to verify the availability of funds or quotas for maintaining the reservation. In multiccist environments, with upstream merging, it is highly probable that more than one usage group would be associated with a reservation. This raises the issue of the “sharing model”, which defines the way by which a reservation may be shared between multiple usage groups.^^ How ever, we believe that it is an issue of LPM local configuration, and therefore would not discuss it here any further. *^It may be reasonable to have a reporting only mechanism that reports the cost to be debited, but falls short of performing actual debiting. ^"Examples for sharing models could be (1) Each policy object is allocated the full cost, (2) The cost is divided equally between the different objects (3) The cost is attributed to an arbitrary object (4) The cost allocated relative to some criteria like the number of downstream receivers, the size of the organization, the eimount of pre-purchased capacity (remaining quota), etc. 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.7.2 M ultiC ost (M C ost) In Chapter 4, we have shown that Equal Link Split Downstream (ELSD) emerged as the most attractive cost allocation scheme. MultiCost enhzinces the simple debiting scenario. Instead of being limited to local information for determining the costs cdlocated to receivers, MultiCost uses the ELSD scheme, which takes into account both the benefits of sharing the multicast distribution and basic concepts of fairness and equality. In Section 5.3 we have presented a simple one-pass, model 2 mechanism for implementing that scheme. We described the mechanism through the following formulation: • The cost allocated to each loczd member is zn(u{)/tmem(u,) • The cost allocated downstream (over link (u,-, uy)) is in{vj) = in{vi) * tmem{vj)ftmem{vi) + c(u,-, uy). 8.7.2.1 O btaining input inform ation To compute this formulation, the following inputs must be available for any node u ,-: (1) tmem(uy), the number of downstream receivers, for each outgoing link (ui, uy) (2) Ni, the number of local receivers and (3) the local cost of the flow, c(u,-, uy), for each outgoing link (u,-, uy). Notice that tmem{vi) = iV ; -f !](«.,«je;, tmem{vj). The first piece of information, the number of receivers downstream to a specific link can potentially be available from future routing protocols, although, current multicast protocols couldn’t be easily modified to provide such information^^ The LPM mechanism could be an alternative way for obtaining the same information: let us define a POLICY_DATA sub-object MCi (for MCost, type-1), which carries the number of receivers downstream. The values of the forwarded M C\ axe computed as the sum of all the MC\ objects received from downstream neighbors plus the number of local receivers Ni?^ The other two pieces of information, the local cost of a flow and the numbers of local receivers can be obtained locally. ■^Most multicast routing protocols (like DVMRP) suppress individual join messages: if two members located in the same sub-net join, and one hears the join message from the other, it will suppress its own join message. •‘ ‘On leaf nodes, the forwarded M C \ object should simply contain the number of local receivers Ni. 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Legend C ^> MC, r:_.j l= > MC: Number of receivers ■ Residual cost allocation Local A PI m Figure 8.7: one-pass, model 2 over LPM 8.7.2.2 A llocating costs to receivers To carry the allocated residual costs downstream, we define a second POLICYJDATA object type MC 2 that corresponds to in{v{) in the model 2 formulation. M C 2 objects are sent downstream, piggybacked on RSVP Report messages, (see Section 8.5.3 about the motivation for the Report message). The overall implementation picture is illustrated in figure 8.7: MCi objects add up the number of downstream receivers as they flow upstream, and MC 2 objects allocate costs to local receivers and next hops, as they flow downstream. 8.7.2.3 Im plem entation for shared channels Performing the one-pass, model 2 mechanism for shared channels complicates the implementation significantly, however, the basic concept remains: MCi objects carry information of receiver numbers upstream and MC 2 objects carry the one-pass cost allocation information downstream. Details of these extensions can be found in Section 7.2.2. 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8.8 Im plem entation experience Our prototype implementation includes the RSVP/LPM interface, the LPM com mon layer, and three POLICYJDATA object handlers: handler 0 for default han dling, handler 1 for simple access control, and handler 2 for MCost cost-allocation. The overall project took several months do develop, and about 10,000 lines of C code. Our prototype was compiled as part of the ISI RSVP implementation. (Code is available upon request). A widely held belief that cissumes that accounting and access control support is complex, and may be difihcult to introduce into resource reservation protocols like RSVP. Considering our discussion about the overall scaling properties of the one-pass cost allocation scheme (and the MultiCost mechanism) we can now disprove this popular belief: our implementation turned out to be quite simple and straightforward, with little difficulty either with the design, or the code development processes. Granted, we have performed limited testing of the prototype implementation, and in Section 9.3, we describe our plans for further development and testing of our implementation. 109 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chapter 9 Sum m ary and Conclusions The original design of the Internet, which supported only a single quality of service (“best effort”) and its historical dependency on heavy government subsidies, con tributed to the meager research interest in the area of internet accounting. How ever, in recent years the Internet has been going through a dramatic transforma tion, with the rapid proliferation and privatization of the infrastructure. As a result, internet service providers and equipment manufacturers are now in great need of solutions for accounting and controlling network resources. Furthermore, internet accounting is considered by many to be a necessary condition for the successful deployment of Integrated Services Packet Networks (ISPN) technology. In this final chapter, we briefly summarize the contributions made in our work, and its overall significance. We conclude with a discussion of future work issues. 110 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 9.1 Contributions The contribution of our work can be roughly divided along the lines of the various research directions we took. 9.1.1 A bstract m odeling In this research, we have made several important decisions: First, that we would investigate cost allocation and not pricing, which means that the total allocated costs are always equal to the total incurred costs. ^ Second, that we would allocate costs to receivers and not to senders.^ Third, that we would evaluate cost allocation schemes in an environment free from mechanistic constraints. To construct such an environment, we developed an abstraction which we call the basic network model. This model provides a formal description of the network technology for multicast transmission, and defines the structure of incurred costs across the network. The network technology follows the multicast model of a source-rooted tree, computed from the union of all the unicast paths between the single source and each of the receivers. Furthermore, the model assumes that all the receivers are provided with the same QoS, and that incurred costs are associated with links. For reasons of simplicity some new and emerging network technologies where not included in the original model. In Chapter 6 we extended the basic model to include some of these new technologies, and described the impact of these extensions on our previous results. 9.1.2 A xiom atic analysis We have argued that the success of cost allocation strategies depend on the social incentives they encourage, and their properties of fairness and equality. In our work we have chosen axiomatic analysis as the methodology for evaluating such proper ties. We formally defined several such properties as basic axioms: these properties represent the very basic notions of fairness and equality, and therefore, are expected to be upheld by any reasonable cost allocation strategy. We then defined the class ^See the discussion in Section 1.3.1 ^See the discussion in Section 1.3.2.1 111 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. of acceptable cost allocation strategies which axe those that comply with the basic axioms. Clearly, this class is quite wide, and may include acceptable, yet less than desirable strategies. Last, we searched for the more desirable strategies; we examined additional properties of fairness and equality as a basis for evaluated specific strate gies (out of the class of acceptable ones). One cost allocation policy. Equal Link Split to Downstream receivers (ELSD) emerged from this evaluation as the most attractive strategy. When extending the basic network model to support shared channels, we have shown that the Equal Link Split to Subscribers (ELSS) strategy turned out as the more general form of the ELSD scheme. 9.1.3 Sim ple and scalable m echanism s We presented a one-pass mechaxiism for cost allocation over multicast distributions. The one-pass mechanism has two different versions (model 1 and model 2). Model 1 imposes no special requirements on routing or reservation protocols, however, it was shown to have relatively poor axiomatic properties. Moreover, it was shown as being unable to implement our most desirable cost allocation scheme (ELSD). By contrast, model 2 requires each node to have additional information about the number of downstream receivers, which may only be available from newer routing and reservation protocols. However, model 2 W cis shown to have excellent axiomatic properties, and the ability to implement the ELSD cost allocation scheme. The two models are very simple to implement and both were shown to have excellent scaling properties. In Section 7.2.2 we described a modified one-pass, model 2, for the shared channel extension to the basic network model. This modified mechanism belongs the one- pass family of mechanisms. However, it does not have the same scaling properties as the original ones. Depending on the exact scenario, its control messages size may be sensitive to group membership. In Section 7.2.4 we discussed the scaling properties of the modified mechanism and suggest some cases where it may scale quite reasonably. 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 9.1.4 Canonical form representation We presented several ways for defining cost allocation strategies. We started with a general description of strategies in Section 3.2. In Section 4.4, we axiomatically evaluated the various cost allocation strategies, and picked the one that turned out to be most attractive. Here we needed a representation that wiU be able to commu nicate our ajciomatic concepts into actual networking technology, being deployed at individual nodes. We introduced the canonical form, which mathematically defines the range of cost allocation strategies as defined by our basic network model. Our results show that if all nodes deploy the exact same formulation of the canonical form (i.e., of the same strategy), then the sum of their individual actions would pro duce the desired cost allocation solution across the entire network. In this work, we presented three distinctive canonical forms: the first, in Section 4.2, defines the set of strategies equivalent to the basic network model and the basic axioms. The sec ond, in Section 5.2.2, defines the set of strategies equivalent to the one-pass, model I mechanism. The third, in Section 6.3.2 is a more general form of the first; it defines the set of strategies for the case of shared channels, that are equivalent to the basic network model and the basic axioms. 9.1.5 T he LPM architecture In Chapter 8 we presented a design for a prototype implementation. Our design is built around the concept of Local Policy Modules (LPM); this architecture defines a modular box that is separate from RSVP and other reservation protocols. The LPM provides general purpose policy enforcement services. It supports a wide range of policies, from simple access control, to usage-based accounting (MCost). The model used by the LPM is that of policy based admission control: by maintaining policy based information about RSVP flows (in the form of POLICYJDATA objects) the LPM is in a good position to teU RSVP whether a reservation should be admit ted. The LPM architecture introduces several important contributions. First, it provides a flexible architecture that allows local configuration and enforcement of policies. Second, it allows multiple accounting and access control mechanisms to inter-operate. Third, it guarantees the stability of RSVP’s functional specifications 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. while maintaining the flexibility necessary for the gradual evolution and reconfig uration of accounting and access control mechanisms. By allowing such gradual evolution, the LPM architecture extends itself beyond the mechanisms described in this work; it may be configured to support policies that have not yet been devised. Currently, we are working on standardization and integration between the LPM and RSVP. Our goal is to turn the LPM architecture into the standard interface for policy enforcement in RSVP. 9.2 Significance o f work A view widely held in the networking community assumes that usage based ac counting for internet traffic, and especially for multicast traflBc, is overly complex, non-scalable, and therefore, impractical. This view prompted many in the commu nity to search for non usage-based mechanisms, that would emulate or approximate usage-based accounting. However, the dynamic nature of multicast complicates such approximations. Currently, we are unaware of any completed work taking this ap proach for multicast distributions. Perhaps the most important goal of this work, was to thoroughly examine the possible approaches to usage-based accounting. We presented cost allocation models for multicast distributions, suggested scalable mech anisms for implementing them, and outlined a design for a prototype implementation (IS a proof of concept. Moreover, because we did not take an ad-hoc approach, the models, mechanisms and methodologies that were developed in this work could fur ther support future evolution of other approaches for internet accounting. 9.3 Future work This dissertation covered extensive ground, from theoretical models all the way to prototype design. In this final section we describe the natural continuation of our research. We roughly divide our future work into three categories: unexplored issues, detailed design ajid implementation, and exploration of new and/or additional policies. 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 9.3.1 U nexplored issues A few issues were left unexplored because we considered them to be outside the scope of this research. First, the issue of dynamicity. in our network model, we assume that the multicast tree is static for some small (6) period of time. However, in large multicast groups, membership can change quite rapidly, and with it, the shape, cost and cost allocation for the tree. If the allocated costs must be equal to the incurred costs, and if the group membership and incurred costs change arbitrarily, one cannot expect the allocated costs to remain constant, or even predictable. We suggest that dynamics is an issue of pricing: cost allocation reflect the current overhead, and therefore must fluctuate. In contrast, consumers usually expect prices to be relatively stable and predictable. We are left with cin unexplored pricing question: given that cost allocation fluctuates, and given that pricing is based on cost allocation, is there a principle that would reduce or eliminate the fluctuation of consumer prices? What would be the ajciomatic toll for using such a principle? The second unexplored issue is the issue of optimality: In our work, we analyzed cost allocation strategies according to their properties of fairness, equality, and mul ticast incentives. We did not explore the issue of incentives for achieving optimal network utilization, which is clearly a very different perspective. The networking community still debates [60] whether the optimality paradigm should be considered as a good evaluation criteria for internet accounting. Our research focused on how global policies for cost allocation can be achieved through distributed, local computation. However, we did not discuss purely local policies that have no global impact. For example, in Section 6.1 we did not discuss how local nodes split the cost between the unordered levels of QoS. We believe that our work could be complimented by an orthogonal research of pure local policies. Last, we did not discuss non usage-based strategies; since they are not based on costs, they belong to the realm of pricing, and not cost allocation. Comparing the two approaches may prove to have interesting and important results. 9.3.2 D etailed design £uid im plem entation The LPM architecture was presented as an approach for supporting access control and accounting in RSVP. However, to realize its integration with RSVP, the LPM 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. design must be followed through the same detailed engineering and standardiza tion process as RSVP. We presented the LPM architecture to the RSVP working group at the lETF^ and we expect to carry this work to completion. Our LPM implementation is currently in prototype state. Before it can be integrated with RSVP’s reference implementations, it must reach a near production status, in terms of completeness,'* generality,® and robustness.® The LPM provides the general mechanism for enforcing multiple policies. In Sec tions 8.3 and 8.7 we described several scenarios of different policies. Our prototype implementation includes three policies: default forwarding, simple access control and MCost. These policies require additional work on design, refinements, and testing. Last, the LPM architecture relies on pre-existing infrastructure, for instance, it assumes the existence of bilateral and/or global agreements. It also assumes that applications, service providers, and authorization/accounting servers would be able to support access control and accounting functionality. The issues related to pre-existent infrastructure are perhaps among the most obscure of aU the elements needed to realize the LPM architecture. This is perhaps because these issues are considered by many to be higher level issues, and not purely networking problems. 9.3.3 A dditional policies In this work, we described the LPM as a general purpose architecture for supporting access control and accounting in RSVP. In this work we concentrated on those several specific policies namely cost allocation strategies, and simple access control. It would be quite interesting and challenging to investigate whether and how the LPM architecture could be applied to other access control or accounting strategies. Three ®The detailed design and steindardization of the RSVP protocol is achieved through the Internet Engineering Task Force (IETF), by the RSVP working group (WG). The RSVP WO produces the RSVP functional specification [8]. The LPM architecture was presented at the Dallas IETF, Dec. 1995. ‘ 'Support for shared channels was the last mechanism we explored on in this work and therefore, is yet to be included in our prototype implementation. ®RSVP’ s reference implementations must be quite general and operate in multiple environments (IPv4 and IPv6, little and big endien machines, support all types of flowspecs, etc.). Our prototype is implemented over the ISI/RSVP code, and currently does not include all of these refinements. ®The LPM architecture had undergone limited testing over DARTNET, however it must be thoroughly tested over more complex and diverse environments. 116 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. interesting new policies come to mind, the RBONE proposal,' Edge Pricing, and Willingness to Pay. The RBONE proposal calls for design ajid deployment of a system for pre registration in RSVP. This would mean that reservations may be treated differently based on whether they are pre-registered or attempted as walk-ins. Edge Pricing is a new paradigm of pricing that was introduced in [60]. This ap proach replaces actual usage metering with approximations. If such approximations can be based on purely local information, one could take advantage of this locality to price network services at the edge (i.e., at the entry point to the network), without having to account for the current network conditions (e.g., actual path). Willingness to pay is an extension of the simple debiting model; it is manifested as a user imposed limit on the cost allocated to it (or the price it is required to pay). Here, the basic idea is that market forces would be the driving force behind what users specify as their willingness to pay. If these new pohcies catch on, it would be interesting to explore the way by which the LPM architecture could support them. With our current understanding of these three policies, we do not foresee any major difficulties there. 'The RBONE proposal is currently part of the Statement of Work of the RSVP-II ARPA contract. 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. R eference List [1] D. Anderson, R. Herritwich, and C. Schaefer. SRP; A Resource Reservation Protocol for Guaranteed Performance Communications in the Internet. Techni cal Report TR-90-006, Computer Science Department, University of California at Berkeley, Feb. 1984. [2] R. J. Aumann and M. Maschler. Came Theoretic Analysis of a Bankruptcy Problem from the Talmud. Journal of Economic Theory, 36:195-213, 1985. [3] F. Baker. RSVP Cryptographic Authentication. Intemet-Draft, draft-ietf-rsvp- md5-02.txt, June 1996. [4] F. Baker, R. Cuerin, and D. Kandlur. Specification of Committed Rate Quality of Service. Internet-Draft, ietf-intserv-commit-rate-svc-OO.txt, Jun. 1996. [5] A. J. Ballardie. Core Based Trees (CBT) Multicéist Architecture. Internet Draft, draft-idmr-cbt-arch-03-txt, Feb. 1996. [ 6] A. J. Ballardie, P. F. Francis, and J. Crowcroft. Core Based Trees (CBT). Proceedings of ACM SIGCOMM ’ 93, Aug. 1993. [7] A. J. Bailaxdie, S. Reeve, and N. Jain. Core Based Trees (CBT) Multicast: Protocol Specification. Internet Draft, draft-idmr-cbt-spec-05-txt, Apr. 1996. [8] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. ReSource Reservation Protocol (RSVP), Version 1 Functional Specification. Internet Draft, draft-ietf- rsvp-spec-12.txt. May 1995. [9] H. W. Braun and K. Clafiy. A Framework for Flow-Based Accounting on the Internet. Proceedings of SICON ’ 93, IEEE Singapore, 1993. [10] N. Brownlee, C. Mills, and C. Ruth. Traffic Flow Measurement: Architecture. Intemet-Draft, draft-ietf-rtfm-arch-report-Gl.txt, Max. 1996. [11] CCITT. Integrated Services Digital Network (ISDN), volume 3 of Recommen dations of the I-series. Red Book, 1985. [12] D. Clark. The Design Philosophy of the DARPA Internet Protocols. Proceed ings of ACM SIGCOMM ’ 88, Aug. 1988. 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [13] D. Clark. A Model for Cost Allocation and Pricing in the Internet. Technical report, MIT, Aug. 1995. [14] D. Clark. Adding Service Discrimination to the Internet. Proceedings of the Twenty-Third Annual Telecommunications Policy Research Conference, 1995. Available from: http://ana-w w w .lcs.m it.edu/am aw eb/ps-papers/ TPRC2-0.ps. [15] D. Clark, S. Shenker, and L. Zhéing. Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism. Proceedings of ACM SIGCOMM ’ 92, Aug. 1992. [16] R. Cocchi. Pricing in Multiple Service Class Computer Communications Net works. PhD thesis. University of Southern California, Computer Science De partment, 1993. [17] R. Cocchi, D. Estrin, S. Shenker, and L. Zhang. A Study of Priority Pricing in Multiple Service Class Networks. Proceedings of ACM SIGCOMM ’ 91, Sep. 1991. [18] R. Cocchi, S. Shenker, D. Estrin, and L. Zhang. Pricing in computer networks: Motivation, Formulation, and Example. IEEE/ACM Transactions on Network ing, Dec. 1993. [19] S. Deering. Host Extensions for IP Multicasting. Internet Request For Com ments, RFC-1112, Aug. 1989. [20] S. Deering. Multicast Routing in a Datagram Internetwork. PhD thesis, Stan ford University, 1991. [21] S. Deering and D. Cheriton. Multicast Routing in Datagram Internetworks and Extended LANs. ACM Transactions on Computer Systems, pages 85-111, May 1990. [22] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. G. Liu, and L. Wei. An Ar chitecture for Wide-Area Multicast Routing. Proceedings of ACM SIGCOMM ’9f, Sep. 1994. [23] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. G. Liu, L. Wei, P. Shaxma, and A. Helmy. Protocol Independent Multicéist-Dense Mode (PIM-DM): Proto col Specification. Internet Draft, draft-ietf-idmr-pim-dm-spec-03.txt, Jan. 1996. [24] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Internet Request For Comments, RFC-1883, Dec. 1995. [25] R.J. Edell, N. McKeown, and P.P. Varaiya. Billing Users and Pricing for TCP. IEEE Journal on Selected Areas in Communications, 13:1162-1175, 1995. 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [26] D. Estrin, D. Farinacci, M. Handley, A. Helmy, V. Jacobson, C. G. Lin, P. Sharma, D. Thaler, and L. Wei. Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. Internet Draft, draft-ietf-idmr-pim- sm-spec-05.txt, June 1996. [27] D. Ferrari and D. Verma. A Scheme for Reail-Time Channel Establishment in Wide-Area Networks. IEEE Journal on Selected Areas in Communications, 8(3), Apr. 1990. [28] J. Forgie. ST - A Proposed Internet Stream Protocol. Internet Experimental Nodes, IEN-199, Sep. 1979. [29] A. Gupta, D. 0. Stahl, zmd A. B. Whinston. The Internet: A Future Tragedy of the Commons. Technical report. University of Texas at Austin, 1995. [30] D. Henriet and H. Moulin. Traffic Based Cost Allocation in a Network. Rand Journal of Economics, 27(2):332-345, Summer 1996. [31] S. Herzog. Accounting and Access Control Policies for Resource Reservation Protocols. Internet Draft, draft-ietf-rsvp-policy-arch-OO.ps, June 1996. [32] S. Herzog. Local Policy Modules (LPM): Policy Enforcement for Resource Reservation Protocols. Internet Draft, draft-ietf-rsvp-policy-lpm-OO.ps, June 1996. [33] S. Herzog. RSVP Extensions for Policy Control. Internet Draft, draft-ietf-rsvp- policy-ext-OO.ps, June 1996. [34] S. Herzog, S. Shenker, and D. Estrin. Sharing the Cost of Multicast Trees: An Axiomatic Analysis. Proceedings of ACM SIGCOMM ’ 95, Aug. 1995. [35] S. Jamin, P. B. Danzig, S. Shenker, and L. Zhang. A Measurement-based Admission Control Algorithm for Integrated Services Packet Networks. Pro ceedings of ACM SIGCOMM ’ 95, Aug. 1995. [36] S. Jamin, S. Shenker, L. Zhang, and D. Clark. Admission Control Algorithm for Predictive Real-Time Service. Proceedings of 3rd International Workshop on Network and Operating System Support for Digital Audio and Video, Nov. 1992. [37] S. C. Littlechild and C. Owen. A Simple Expression for the Shapley Value in a Special Case. Management Science, 20:370-2, 1973. [38] J. K. MacKie-Mason, J. Murphy, and L. Murphy. The Role of Responsive Pric ing in the Internet. Technical report. University of Michigan Dublin City, and University of Auburn, June 1995. Available from h ttp : / / w w w . sp p . umich. edu/ sp p /p a p ers/j m m/responsive-m it96-net.p s .Z. 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [39] J. K. MacKie-Mason and H. R. Varian. Pricing Congestable Network Re sources. IEEE Journal on Selected Areas in Communications^ 13:1141- 1149, 1995. Available from f tp : / / gopher. econ.Isa.um ich. edu/pub/Papers/ p ricing-congest ib le . p s .Z. [40] J. K. MacKie-Mason and H. R. Varian. Pricing the Internet. In B. Kahin and J. Keller, editors. Public Access to the Internet. Prentice-Hall, Englewood Cliffs, NJ, 1995. Available from http://w w w .spp.um ich.edu/spp/papers/ jm m /Pricing_the_Intem et .ps .2. [41] N. Megiddo. Computational Complexity of the Game Theory Approach to Cost Allocation for a Tree. Mathematics of Operations Research, 3:189-196, 1978. [42] P. Metzger and W. Simpson. IP Authentication using Keyed MD5. Internet Request For Comments, RFC-1828, Aug. 1995. [43] C. Mills, D. Hirsh, and G. Ruth. Internet Accounting: Background. Internet Request For Comments, RFC-1272, Nov. 1991. [44] D. J. Mitzel, D. Estrin, S. Shenker, and L. Zhang. An Architectural Comparison of ST-II and RSVP. Proceedings of IEEE Infocom ’ 94, June 1994. [45] D. J. Mitzel and S. Shenker. Asymptotic Resource Consumption in Multicast Reservation Styles. Proceedings of ACM SIGCOMM ’ 94, Sep. 1994. [46] P. V. Mockapetris and K. J. Dunlap. Development of the Domain Name System. Proceedings of ACM SIGCOMM ’ 88, pages 367-378, 1988. [47] H. Moulin. Uniform Externalities: Two Axioms for Fair Allocation. Journal of Public Economy, 43:305-326, 1990. [48] H. Moulin. Welfare Bound in the Cooperative Production Problem. Games and Economic Behavior, 4:373-401, 1992. [49] H. Moulin and S. Shenker. Average Cost Pricing versus Serial Cost Sharing: An Axiomatic Comparison. Journal of Economic Theory, 64(1):178-201, 1994. [50] J. Moy. Multicast Extenison to OSPF. Internet Request For Comments, RFC- 1584, Mar. 1994. [51] J. Moy. OSPF Version 2. Internet Request For Comments, RFC-1583, Mar. 1994. [52] R. B. Myerson. Game Theory. Harvard University Press, Cambridge, Mas sachusetts, 1991. 121 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [53] H. Peyton-Young, editor. Cost Allocation: Methods, Principles, Applications. Elseviers Science Publishers, B.V., Amsterdam, The Netherlands and New York, N.Y., U.S.A., 1985. [54] A. E. Roth, editor. The Shapley Value, an Essay in Honor of Lloyd S. Shapley. Cambridge University Press, Cambridge, 1988. [55] L. S. Shapley. Notes on the N-Person Geime II: the value of an N-Person Game. RAND RM, page 670, 1951. [56] L. S. Shapley. A Value for N-Person Games. In H. W. Kuhn and A. W. Tucker, editors. Contributions to the Theory of Games, Vol. II, Annals of Mathematics Studies No. 28, pages 307-317. Princeton University Press, 1953. [57] W. W. Sharkey. Network Models in Economics. In M.O. Ball et al., editor. Handbook of Operations Research and Management Science: Networks, Volume 8, pages 713-765, 1995. [58] S. Shenker. Maldng Greed Work in Networks: A Game-Theoretic Analysis of Switch Service Disciplines. Proceedings of ACM SIGCOMM ’9f, Aug. 1994. Available from f tp : / / f t p .pare.xerox, com /pub/net-reseach/greed-cr.ps. [59] S. Shenker. Service Models and Pricing Policies for an Integrated Services Internet. In B. Kahin and J. Keller, editors. Public Access to the Internet. Prentice-HaU, Englewood Cliffs, NJ, 1995. [60] S. Shenker, D. Clark, D. Estrin, and S. Herzog. Pricing in Computer Networks: Reshaping the Research Agenda. Telecommunications Policy, 20(1), 1996. also published in Proceedings of the Twenty-Third Annual Telecommunications Pol icy Research Conference, 1995. [61] S. Shenker, D. Clark, and L. Zhang. A Scheduhng Service Model and a Schedul ing Architecture for an Integrated Services Packet Network. Technical report. Xerox PARC, 1994. [62] S. Shenker, C. Partridge, and B. Davie. Specification of Predictive Quality of Service. Intemet-Draft, ietf-intserv-predictive-svc-01.txt, Nov. 1995. [63] S. Shenker, C. Partridge, and R. Guerin. Specification of Guaranteed Quality of Service. Intemet-Draft, ietf-intserv-guaranteed-svc-05.txt, Jul. 1996. [64] S. Shenker, C. Partridge, and J. Wroclawski. Specification of Controlled Delay Quality of Service. Intemet-Draft, ietf-intserv-control-del-svc-02.txt, Nov. 1995. [65] S. Shenker and J. Wroclawski. Network Element Service Specification Template. Intemet-Draft, ietf-intserv-svc-template-02.txt, Nov. 1995. 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [66] C. Topolcic. Experimental Internet Stream Protocol: Version 2 (ST-II). Inter net Request For Comments, RFC-1190, Oct. 1990. [67] D. Waitzman, C. Partridge, and S. Deering. Distance Verctor Multicast Routing Protocol. Internet Request For Comments, RFC-1075, Nov. 1988. [68] Q. Wang, J.M. Peha, and M.A. Sirbu. An Design of an Optimal Pricing Scheme for ATM Integrated-Services Networks. In Special Issue of Internet Economies, Journal of Electronic Publishing. University of Michigan Press, Oct. 1995. Available from ftp : //www. e ce. emu. edu/af s /e c e . emu. edu/usr/peha/ opt_priee.P S.Z. [69] L. Wei and D. Estrin. The Trade-offs of Multicast Trees and Algorithms. Tech nical Report TR93-560, University of Southern California, 1993. [70] L. Wei and D. Estrin. Multicast Routing in Dense and Spzirse Modes: Simula tion Study of TradeoflFs and Dynamics. Technical Report TR93-613, University of Southern California, 1995. [71] J. Wroclawski. Specification of the ControUed-Load Network Element Service. Intemet-Draft, ietf-intserv-ctrl-load-svc-01.txt, Feb. 1996. [72] D. ZappaJa. Multicast Routing Support for Integrated Services. Ph.D. Disser tation Proposal, University of Southern California, Computer Science Depart ment, 1995. Work in progress; available from ftp ://c a ta rin a .u s c .e d u /p u b / daniel/RSRR/quals.ps. [73] H. Zhang and E. W. Knightly. Providing End-to-End Statistical Performance Guarantee with Bounding Interval Dependent Stochcistic Models. Proceedings of ACM SIGMETRICS ’ 94, pages 211-220, May. 1994. [74] L. Zhang, S. Deering, D. Estrin, S. Shenker, and D. Zappala. RSVP: A New Resource Reservation Protocol. IEEE Networks Magazine, Sep. 1993. [75] Two hold a garment. The Jewish Book of the Mishna, Baba Metzia 2a. 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

A distributed access control mechanism for managing intellectual property rights in large-scale information systems

PDF

An adaptive multi-class call admission control for multimedia wireless networks.

PDF

Application characterization and performance evaluation for integrated services networks

PDF

A process elaboration formalism for writing and analyzing programs

PDF

A measurement-based admission control algorithm for integrated services packet networks.

PDF

Adaptive Source Routing Of Real-Time Traffic In Integrated Services Networks

PDF

Algorithms for the discrete logarithm problem and algebraic aspects of quantum computation

PDF

A Neural Code For Face Representation: From V1 Receptive Fields To It 'Face' Cells

PDF

A potential field method for the automatic design of modular fixtures

PDF

A divide-and-conquer computer

PDF

A software project dynamics model for process cost, schedule and risk assessment

PDF

Simulation Performance Vs. Simulation Timing Granularity

PDF

A uniform framework for efficient data remapping

PDF

A unified approach to the construction of correct concurrent programs

PDF

Bayesian analysis of software cost and quality models.

PDF

An empirical investigation of engineering design solution exploration using three design elements approaches.

PDF

Applications of abstract data types: The Trio operating system.

PDF

An algebraic view of protection and extendibility in abstract data types

PDF

Annotation databases for distributed documents

PDF

A CMOS Clock and Data Recovery circuit for Giga-bit/s serial data communications

Asset Metadata

Creator Herzog, Shai (author)

Core Title Accounting and access control for multicast distributions: Models and mechanisms

Contributor Digitized by ProQuest (provenance)

Degree Doctor of Philosophy

Degree Program Computer Science

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Computer Science,Engineering, System Science,OAI-PMH Harvest

Language English

Advisor Estin, Deborah (committee chair), [illegible] (committee member), Silvester, John (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c17-517646

Unique identifier UC11350131

Identifier 9705108.pdf (filename),usctheses-c17-517646 (legacy record id)

Legacy Identifier 9705108.pdf

Dmrecord 517646

Document Type Dissertation

Rights Herzog, Shai

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA