The Tussle Analysis Cookbook

The Tussle Analysis Cookbook
Seventh Framework CSA No. 258138
Socio-Economic Services for European Research Projects (SESERV)

European Seventh Framework Project FP7-2010-ICT-258138-CSA
The SESERV Consortium

University of Zrich, UZH, Switzerland University of Southampton, IT Innovation Centre, U.K. Athens University of Economics and Business - Research Center, AUEB-RC, Greece University of Oxford, UOX, U.K. Alcatel Lucent Bell Labs, ALBLF, France AtoS Origin, AOSAE, Spain
Copyright 2013, the Members of the SESERV Consortium

For more information on this document or the SESERV support action, please contact: Prof. Dr. Burkhard Stiller Universitt Zrich, CSG@IFI Binzmhlestrasse 14 CH8050 Zrich Switzerland Phone: +41 44 635 4355 Fax: +41 44 635 6809 E-mail: info@seserv.org
Document Control
Title: Type: Editor(s): E-mail: Author(s): Doc ID: The Tussle Analysis Cookbook Public Costas Kalogiros ckalog@aueb.gr Costas Kalogiros (AUEB), J Brian Pickering (IT Innovation), Martin Waldburger (UZH), Patrick Poullie (UZH), Burkhard Stiller (UZH) TA cookbook-v1.0.doc
AMENDMENT HISTORY
Version
V1.0
Date
Dec ember 21, 2012
Author
Costas Kalogiros, J Brian Pickering, Martin Waldburger, Patrick Poullie, Burkhard Stilller
Description/Comments
Final version completed
Legal Notices The information in this document is subject to change without notice. The Members of the SESERV Consortium make no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The Members of the SESERV Consortium shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material.
Table of Contents
1. Introduction ....................................................................................................................4 2. Why Use Tussle Analysis? ............................................................................................4 3. How to Perform the Tussle Analysis Methodology? ......................................................8 4. A Tussle Analysis Case Study: Reciprocal Traffic Forwarding ....................................16 5. Conclusions .................................................................................................................18 6. References ..................................................................................................................20
1. Introduction
The Internet is a platform that can be studied as a system composed of multiple technologies and an environment where multiple stakeholders interact by using those technologies. At the socioeconomic layer stakeholders have interests, expressed by making choices governed by laws of economics (e.g., supply and demand), sociology, or psychology. Such choices affect the Internet technology layer by specifying the technologies to be introduced, how these will be dimensioned, configured, and finally, used. This phenomenon makes Internet interesting not only to technology developers but economists and social scientists, as well. For example the DNS (Domain Name System) associates domain names to network addresses in a distributed way, based on each administrator's configuration of their local DNS server's entries. These entries can affect the level of caching achieved and be used for other purposes, such as load balancing and optimized delivery of services and contents to end-users. Similarly, routers interconnected through physical links forward data packets (Best effort or QoS-enabled) based on each ISP's configuration of the Border Gateway Protocol (BGP). To provide an example of how complex these interdependencies may be, networks (named Autonomous System) are multihomed in order to assure redundancy, but also the opportunity to choose a particular provider by announcing multiple DNS and/or BGP entries. This natural and continuous quest of Internet stakeholders for achieving their goals defines a "tussle" [1]. Thus, a tussle does not involve the interests of the stakeholders only, but how these conflicting interests are expressed through the available technologies. The combination of actors' policies at a given point in time, which takes into account other stakeholders' socio-economic decisions and the restrictions imposed by the current technology set, leads to a tussle outcome. These outcomes are rarely static and the emergence of new technologies and stakeholders, the adoption of new strategies, or introduction of new regulatory constraints can trigger the transition to new outcomes. All these interactions allow the Internet to evolve and act as a living organism. There is a growing number of researchers in the Internet community suggesting that standardized technologies should have taken into account the incentives of all major stakeholders during the design phase. Clark et al. [1] have described two new design principles that implement the "Design for Tussle" goal. In a similar line of thought [2] proposes three practical rules for avoiding the development of technologies that do not capture key aspects of their socio-economic environment. SESERV coordination project has defined a systematic approach for analyzing and assessing the importance of socio-economic tussles in the Internet [3]. The main idea is to make sensible predictions about the behavior of major stakeholders in several scenarios, each scenario reflecting candidate implementations of the desired protocol function. We argue that selecting the features of a technology in a more holistic way, by taking into account the Internet socio-economic layer would lead to more attractive outcomes and increase the chances of that technology to be adopted in the long-term.
2. Why Use Tussle Analysis?

It is natural that some stakeholders have conflicting interests when making technology decisions. As shown in Figure 1, the long-term goals of each stakeholder with respect to a specific Internet function define its strategy that is, finally, implemented by policies. These policies take into account the technology restrictions and other stakeholders socio-economic aspects. The decisions contained in these policies can be mostly grouped into the following categories (in practice): Adopt a suitable technology from the set of available ones for the function in question
Dimension dedicated resources to support the goals of the stakeholder Configure parameters of the technology that affect how function in general is provided Configure parameters that affect how function for a specific instance is provided
This process defines a tussle between the stakeholders, reflecting their conflict of goals at the socio-economic layer. However a tussle does not involve the interests of the stakeholders only, but how these conflicting interests are expressed through the available technologies. The combination of actors policies leads to a tussle outcome.
Figure 1: Basic technology cycle due to conflicting socio-economic interests For example, end-users may: a. choose to use a specific application for content distribution based on its ability (or not) to download from multiple sources simultaneously, b. select the upper and lower limits of the upload/download capacity for that application (based on its connectivity profile), c. configure maximum number of TCP connections per downloaded file, and/or d. set priority for queued files based on number of available sources. ISPs may: a. measure the performance of web-browsing connections and observe that these obtain a small bandwidth share, and b. add capacity to alleviate the problem. In general, policies are applied in an order similar to the one presented above and may evolve using feedback from the history of the system. Eventually the process is expected to lead to a tussle outcome, which is characterized by the benefit or satisfaction that each stakeholder gets, defined by appropriate utility functions at the socio-economic layer. The level of benefit can vary substantially among stakeholders, some of which may consider the outcome of a tussle as unfair. Different concepts of fairness may apply depending on the social context. For simplicity it is assumed that all stakeholders agree on what constitutes a fair outcome. If the given outcome is not stable, because certain stakeholders consider it as unfair, then it is likely to trigger a new tussle cycle, where some other (possibly, more radical) changes take place in the space of the adopted technologies.
It is likely that unstable outcomes will lead to a new tussle and possibly destabilize other functional spaces as well. This is called a spillover effect. It should be noted that stable tussle outcomes can also create spillovers to other functions, in case some users of the established function find some new uses of it, not anticipated before, which interfere with other functions of the ecosystem. These are cases of negative externalities (i.e. adverse effects) between different functional spaces. Positive externalities may also appear, for example more resources become available due to the introduction of a more efficient technology to a complementary function. In what follows, consequences of negative externalities are studied, unless explicitly mentioned. Such negative effects usually happen when the assumptions made during the design phase of a technology implementing a particular function do not hold anymore and allows a tussle of a different function to reach an unfair outcome. These effects can also happen when a technology that is used during a tussle, can be repurposed and used in a way that imbalances a different tussle of another function (which may involve different stakeholders). SESERV believes that analyzing the anticipated tussles can shorten unstable periods and help the adoption of a long-term successful technology and configuration. Figure 2 presents how the total benefit is allocated, as each type of stakeholders adopts new, biased technologies. The idea is that technology developers identify the potential for a new technology that meets the interests of only one stakeholder group, for example the blue ones, and at time T0 these stakeholders start adopting it. This decision results in blue stakeholders receiving higher payoff than the green ones, which the society (as a whole) considers to be unfair. This situation is an opportunity for another developer to come up with a new technology that favors the green stakeholders. Thus, at time T1 green stakeholders start deploying this technology resulting in a gradual shift in how welfare is split. In particular, we assume that green stakeholders achieve the highest total benefit at time T2, when the blue stakeholders adopt a new non-neutral technology.
Figure 2: Two stakeholder types seeking to split the total net benefit by adopting new technologies
This pattern of conflicting interactions could continue as long as there is sufficient demand by the two stakeholder types in buying new applications for that particular Internet function. We could assume that in the long-run both stakeholder types are equally satisfied (that is they receive a fair share of the total welfare). This would be ideal not only for the two stakeholders, but the community of developers as well. Thus, designing non-neutral technologies does not exclude the possibility of achieving fair outcomes, but as we will explain below these outcomes can be less efficient than those achieved if the design for tussle paradigm had been followed. The main reason is that sometimes spillovers to other functions occur, which reduce the benefit of one or more stakeholder groups. In our example, such negative externalities appear at time T5 and lets assume these affect the blue stakeholders.
SESERV believes that applying the tussle analysis methodology is beneficial for the wider Internet community. Figure 3 describes the same scenario, the main difference being that at time T2 the green stakeholders adopt a technology following the design for tussle approach. This gives them the opportunity to configure the technology (at times T3, T4 and T5) in a way that will gradually lead to a stable and fair outcome, while at the same time avoiding spillovers to other functions.
Figure 3: Two stakeholder types seeking to split the total net benefit by configuring a tussle-friendly technology
Technologies satisfying Clarks Design for Choice Principle provide the involved stakeholders (e.g., users and providers) with the ability to express their interests and affect the outcome at runtime. The rationale is that Internet is a rather unpredictable system and it is very difficult to assess at design time whether a particular outcome will remain desirable in the future. Thus, Internet technologies should be designed for allowing variation in outcome instead of imposing a particular one. Since reconfiguring a technology happens at a faster time-scale than adopting a new one (see Figure 1), reaching a stable outcome is easier. Furthermore, Clarks second principle related to the Design for Tussle goal, namely Modularize along the tussle boundaries helps in avoiding spillovers to other functions. This means that although negative externalities are not eliminated, their impact on total net benefit is mitigated. However, it is true that taking into consideration the important socio-economic aspects of a technology can increase developers cost significantly. This is mainly attributed to the need for extensive and careful definition of stakeholders requirements and consequently increased time to market. This leads us to the natural question: What are the incentives of technology developers in following the Design for Tussle principle? The main argument comes from Clark again; fear and greed. Developers compete with each other and thus will have the incentive to adopt tools and methodologies that make their arte facts more attractive. A famous example of technology being compatible to the Design for Tussle principles and having succeeded is the Session Initiation Protocol (SIP) for managing VoIP calls. The highly flexible configuration of SIP forced competing technologies (such as H.323 suite of protocols) to redefine their design. Furthermore, new configuration options may appear in the future, thus it is unlikely that developers focusing on a particular function will run out of business. Finally, technology makers can employ tussle analysis methodology as a strategic instrument for assessing (at design-time or even earlier) which technologies to invest in, identifying missing components/design flaws in existing technologies or for anticipating market adoption chances. In a similar line of thought, tussle analysis can be used as a strategic instrument for standardization bodies, research funding agencies and policy makers when selecting on which technologies to focus standardization efforts on, or to be funded (giving incentives to technology
makers to deal with the most critical functions). Based on the consolidated results of the detailed tussle analysis that was performed for 8 research projects in [6] SESERV concluded that the Network Security function creates many spillovers to other networking functions, and especially the Transmission one. This gives significant evidences that in order for the Future Internet to successfully provide advanced services, technologies are necessary that will bring more transparency and trust. Finally, tussle analysis can be used for exchanging knowledge between technology makers and other experts (e.g., social scientists); achieving a common understanding of the main challenges and agree on possible countermeasures. In the next section we describe the proposed methodology for systematically analyzing and dealing with socio-economic tussles in the Internet. The aim is to provide a cookbook for developers that will guide them in applying the SESERV tussle analysis methodology. This cookbook explains the steps of the methodology, provides methods and tools suitable for each step as well as taxonomies that can act as a starting point. Furthermore, the methodology is applied to a case study from a FP7 European research project, called ULOOP.
3. How to Perform the Tussle Analysis Methodology?

The SESERV tussle analysis methodology, initially outlined in [3], can be useful when designing new Internet technologies for understanding the expected impact to the stability and efficiency of that particular functional space and possible spillovers to other spaces. As explained in the previous section, selecting the features of a technology in a more holistic way, by taking into account the socio-economic requirements would lead to more attractive outcomes and increase the chances of that technology to be adopted in the long-term. This methodology actually defines a systematic approach for guiding the developers in answering the following questions: Is a new technology needed today and why? o o o What are the interests of existing stakeholders today? What options do existing technologies offer to stakeholders? What are the properties of existing outcomes in terms of performance and stability?
What would be the effect of a new technology to the ecosystem in the future? o o How would the interests of existing and new stakeholders be affected? How would the options of existing and new stakeholders be affected?
Can this technology help reaching a fairer outcome regarding this function, or increase efficiency in the case of an already stable outcome?
The proposed methodology is the following: 1. Identify all primary stakeholder roles and their characteristics for the function under investigation. 2. Identify tussles among identified stakeholders. 3. For each tussle: a. Assess the impact to each stakeholder (short-term, mid-term or long-term depending on the context); b. Identify potential ways to circumvent any resulting spillovers. For each new circumventing technique, apply the methodology again.
Figure 4 gives a high-level view of tussle analysis methodology and the purpose of each step. Each step is shown as a horizontal rectangle with arrows denoting transitions. The purpose of each step is depicted as a diamond while the color determines whether that task refers to the present situation or a future ecosystem. All steps are applied in the context of one, or more, functions (rounded vertical rectangles).
Figure 4: High-level view of tussle analysis methodology Initially we apply the methodology for Function I, based on the responses to the relevant questions, for a technology set S that covers existing technologies. The following possibilities apply with respect to how the analysis will proceed: If some stakeholders do not consider the tussle outcome fair, then we have to perform another iteration after the introduction of the proposed technology (technology set S). If some stakeholders consider the tussle outcome of Function II due to a spillover unfair, then we have to perform an iteration for the technology set S, which includes the initial technology set and the proposed technology.
If any of the conditions above does not hold we need to examine the specific tussle in more detail to establish what might be done to restore equilibrium between the stakeholders involved. In the following we provide a detailed description of each of the steps including techniques that can be utilized for successfully performing the tussle analysis.
Step 1: Identify all primary stakeholder roles for the function under investigation The first step suggests composing the socio-economic and technology landscape for a particular function of the technology under investigation. One technology may perform more than one
functions and it is very probable that multiple technologies are available for the same function, as well. In order to make those 'functions' more concrete we decided to use an extensive taxonomy of Internet functions, which covers both aspects of how services are being hosted (cloud-related functions) and their actual delivery (network-related functions). To avoid reinventing the wheel, we adopted the network functions taxonomy as described in [8]. The reason for selecting this particular taxonomy is that each function is well separated from other complementary ones. While each of these functions can be decomposed further into sub-functions, they can also be seen as components for composing more complex network services.
Figure 5: A Taxonomy for Internet Functions More specifically:
The Transmission function was suggested to include sending, receiving, forwarding, routing, switching, storing, and processing of data packets or, in general, PDUs (Protocol Data Units). The Traffic control function includes flow and congestion control (for tuning the transmission rate parameters), as well as error control for dealing with lost and out-of-order PDUs. The QoS (Quality of Service) function would cover queuing algorithms, admission control techniques and mechanisms for managing QoS-aware paths (e.g., advertisement of infrastructure availability and current workload, setup of Diff-Serv classes). The Mobility function would include protocols for handover and location management. The Security function would cover protocols for authentication, authorization, accounting, monitoring, encryption, redundancy, data integrity, and key distribution. The Naming/Addressing function would include naming schemes and name resolution techniques.
Being unable to find a suitable taxonomy for cloud functions we proposed the following one:

Virtualization, which includes image creation, image deactivation, image portability (to different machines). Execution, which includes low-level tasks such as Task scheduling (at the CPU level), Task execution (at the CPU level), memory allocation and similar aspects related to Operating Systems. QoS, which includes advertisement of site availability, site selection, machine selection, machine reservations, admission control (for performance reasons), cost allocation. Security that includes monitoring, accounting, SLA management, admission control (for security reasons).
It is important to note that each function should achieve its initial target, instead of other purposes that were found later (spillover). For example, techniques for DPI (Deep Packet Inspection) should not be part of the QoS function, but MPLS signaling for setup of QoS-aware paths perfectly fit there.
Figure 6: Stakeholder roles in the Future Internet Having identified the function under investigation, the next task is to identify and study the properties of the most important stakeholder roles. These stakeholders make decisions that affect the outcome or have a vested interest in the outcome. We are interested in stakeholder roles
instead of specific entities, even though the latter can be useful for understanding the context. [6] presents a synthesis and classification of Future Internet stakeholder roles into 7 categories by SESERV. For the rest document, we will refer to stakeholder roles when mentioning stakeholders, unless explicitly mentioned. The reason for this abstraction is that the same entity may take multiple roles in a particular instance of that function, or take a single role that can differ across instances of that function. Besides recognizing the set of stakeholder roles their characteristics must be understood. The most important attribute of a role is the goal to be met through this function, even though differences on the intensity may exist depending on the technology literacy and expectations, openness to risk and innovation. Information about the group population and other qualitative measures may be useful during the next steps of the methodology. Finally we need to specify the technologies (complementary or substitute ones) that can be used for a service or application instance related to that function. These technologies, or technology sets, usually follow a different logic or may not even be designed for implementing that function. Useful methods for performing the first step of the tussle analysis methodology are the following: Interviews, which are the most widespread techniques for gaining information about a situation from the stakeholders involved, or other experts. Starting from an initial set of candidate stakeholders, interviews can help validate their involvement and identify new ones. Personal observation that is another method to understand how stakeholders react to certain circumstances. Own experience or related literature can be used, as well, when it is difficult to study the value network.
Step 2: Identify tussles among identified stakeholders. Identifying such alternative technology schemes will be useful in performing the second step, which refers to identifying tussles among the set of stakeholders. More specifically when a conflict of interest is found to exist between some stakeholders, we should seek for policies enabled by the technologies that these rational entities would select in order to meet their goals. To address this step in a more systematic way, an initial set of tussle patterns was identified. These tussle patterns, described in more detail [3] (including their relationship to situations that are well known in the economic theory literature known such as information asymmetry), are: Contention where two or more actors compete for access to a shared resource. Repurposing where an actor would want to use a resource for an interest or in a way not envisaged by the resource owner. Responsibility where an entity attempts to identify who should be accountable for an action that is against its interests when many actors are involved. Control where two or more actors have different views on how a set of complementary resources should be combined.
SESERV had performed a survey regarding the key socio-economic challenges of interest to 16 FP7 research projects [5]. It was found that several projects study interactions between stakeholders that can be categorized into a limited number of groups, such as network security, controlling content/service delivery and responsibility for agreement violation, among others. The following table provides a listing of these tussle groups and, for each one, a popular tussle among the projects. Useful methods for performing the second step of the tussle analysis methodology are the following: SWOT analysis as a framework for understanding the (S)trengths, (W)eaknesses, (O)pportunities and (T)hreats facing a particular stakeholder at a given situation. It assumes
knowledge of the major stakeholders and tries to identify tussles by predicting how they could harm that particular stakeholder, as well as the opportunities of the latter one. The MACTOR method (Matrix of Alliances and Conflicts: Tactics, Objectives and Recommendations) [9],[10], which attempts to give an overview of possible alliances and conflicts in a business ecosystem. Having identified the set of stakeholders, this approach tries to document candidate tactics that could lead to other outcomes and then evaluate the attractiveness of each outcome to participants. Focus groups that examine how knowledge and, more importantly, how ideas both develop, and operate, in a given cultural context [7]. This technique can offer a structured approach for identifying, communicating, and addressing socio-economic aspects of Internet technologies by bringing together a broad range of stakeholders. Thus, focus groups are perfectly suited for understanding the dynamics of the major tussles by observing stakeholders views. Table 1: Tussle groups and popular tussles Tussle Groups Network Security Interconnection Agreements Allocation of scarce resources Responsibility for agreement violation Routing Service Requests (selecting a provider to fulfill a customer request) Controlling content/service delivery (referring to possible anti-competitive tactics) Controlling access to sensitive data Popular Tussles Stop DDoS attacks near the source ISP Imbalance traffic ratios using local content Capacity of a common link/frequency Effort in serving a customers request Brokers serve customer requests using different optimization criteria Filter user requests for service (walled garden)
Reusing data of previous sessions
Focus groups have been extensively used by SESERV at various events for bringing technologists, social scientists, policy makers and end-users together to discuss a particular topic. More specifically, 4 focus groups have been organized with a tussle-oriented goal. After presenting a high-level overview of the technology under study, each stakeholder representative 1 expressed her opinions allowing conflicts of interest to be identified and discuss how these would evolve. Having gained significant experience, SESERV has offered a set of recommendations on preparing and running focus groups, which are not restricted to tussle analysis. These can be summarized in the following list, but the interested reader is encouraged to see D1.5 for more details [7]:
1
Participants chose their stakeholder role in the beginning of the focus group (first step of the tussle analysis methodology).
The overall Focus Group Methodology as defined in the literature should be tailored to the specific needs of any individual focus group or area. Careful consideration of group composition is vital. There has to be sufficient diversity to encourage discussion, however, groups that are too heterogeneous may result in conflict and the repression of views of certain individuals. A small group of individuals, usually between six and ten people is expected to strike a good balance between effectiveness and plurality of opinions. Successful recruitment may depend on the accessibility of the venue to participants. For this reason it is important for focus groups to be held at places close to the participants (if possible a venue which is familiar to the members of the focus group should be chosen). The moderators role is very important in facilitating the discussion and can vary between low and high levels of steering. Regardless of the intervention level, she should not influence the discussion by offering an opinion, supporting/criticizing/praising any individual view. Furthermore, it is important that no participant dominates the discussion; quieter participants should be encouraged to contribute, as well. Having audio recordings of sufficient quality is important for transcribing the sessions. Participants should be informed about that beforehand. The duration of the focus group is important and must be communicated to participants beforehand. The length should be enough for all participants to express their views and cover the topic(s) in enough detail. Even if the group is going very well and the group members appear very enthusiastic, the facilitator is suggested asked to wind things up after 90 minutes.
Step3: For each tussle assess the impact to each stakeholder The third step of the methodology aims to evaluate each tussle outcome from the perspective of each stakeholder (in order to infer the stability properties of the function under investigation) and understand its effects on the stability of other functions. Useful methods for performing the second step of the tussle analysis methodology are the following: Focus groups can help in assessing whether a technology is "biased" or not, and in the first case participants have the chance to find those "control points" making this technology more "Designed for Tussle" (that is the involved stakeholders have enough control to determine the outcome by negotiating/tuning this control point). Game theory is a branch of mathematics that aims at finding and evaluating the possible equilibrium outcomes, for a specific scenario in a system with rational participants. Multiple rounds of actions can be considered, but at the trade-off of increased complexity. Risk analysis is a method for identifying candidate factors that can have a negative effect on a system and quantitatively or qualitatively evaluate those effects in order to take precautions. System dynamics is another method for simulating the possible outcomes (e.g., a technology reaching the critical mass adoption level) when multiple stakeholders interact.
In the ideal scenario of a tussle outcome is an equilibrium point, where: a) all stakeholders of that Internet function derive a fair 2 payoff (thus no one will select another policy) and b) no stakeholder of another Internet function, who was receiving a fair payoff before, gets an unfair payoff after that tussle equilibrium has been reached. If both conditions hold the analysis of this particular tussle is completed and we can move on to the remaining tussles identified in Step 2. In the case where condition (a) is not met, the analyst should examine whether a change in the implementation details would lead to a more stable outcome. Similarly, a new iteration must be performed for each spillover to other functions when condition (b) is not met. Clark et al. [1] has provided two design principles that can help a developer in designing tusslefriendly technologies; Design for Choice and Modularize along the tussle boundaries. The Design for choice principle provides guidance in designing protocols that allow for variation in outcome. Useful properties are: Exposure of list of choices suggesting that the stakeholders involved must be given the opportunity to express multiple alternative choices and which the other party should also consider. Exchange of valuation suggesting that the stakeholders involved should communicate their preferences in regard to the available set of choices (for instance by ranking them in descending order). Exposure of choices impact suggesting that the stakeholders involved should appreciate what the effects of their choices are on others. Visibility of choices made suggesting that both the agent and the principal of an action must allow the inference of which of the available choices has been selected.
The Modularize the design along tussle boundaries principle helps in identifying whether tussle spillovers can appear. A protocol designer can check any of the following two conditions: Stakeholder separation, or whether the choices of one stakeholder group have significant side effects on stakeholders of another function (another tussle space), for example creates economic externalities between stakeholders of different tussle spaces. Functional separation, or whether different stakeholders use some function of the given technology in an unforeseen way to achieve a different goal in some other tussle space, i.e., the function of technology A interferes with (and possibly cancels) a function of technology B.
Table 2 provides an overview of such popular methods (rows) and their suitability to carry out a particular step (columns).
It is obvious that the definition of fairness is very important when interpreting tussle outcomes. For example, a challenging scenario is to assess fairness when the conflicting interests come from different paradigms such as social values vs. economic goals.
Table 2: Popular Methods Overview Stakeholder Identification Interviews Personal observation Focus groups MACTOR SWOT analysis Game theory Risk analysis System dynamics Highly relevant Highly relevant Relevant Prerequisite Prerequisite Prerequisite Prerequisite Prerequisite Tussle Identification Relevant Highly relevant Highly relevant Highly relevant Relevant Prerequisite Highly relevant Prerequisite Tussle Impact Tussle Evolution Relevant Less relevant Highly relevant Relevant Relevant Highly relevant Highly relevant Highly relevant and
In the following section we perform the tussle analysis methodology to a specific technology. The interested reader can find more case studies in [6].
4. A Tussle Analysis Case Study: Reciprocal Traffic Forwarding

The ULOOP project 3 follows an evolutionary approach for the Future Internet, suggesting that overlapping Wi-Fi access networks, operated mostly by end-users, could form a wireless localloop that complements or in some cases substitutes the ISPs infrastructure. Thus the core ULOOP software will perform functions related to Transmission, but in order to foster the creation of a collaborative environment allowing robust, trustworthy, low-cost, and energy-efficient communications to take place ULOOP technologies will also perform Security-related functions. Figure 7 below presents the tussle evolution. Functions are represented as rectangles, while related stakeholders appear on the left of each rectangle. The vertical positioning of an outcome denotes whether it considered fair or not. For this reason we assume that a neutral stakeholder exists, placed near the middle of each rectangle, and we use a white background color to denote this. Finally, each spillover appears as a red, dotted arrow. 1st iteration Focusing on the Transmission function (grey rectangle in Figure 7), the first step involves the identification of major stakeholders involved. The stakeholders in this particular case are mainly end-users adopting ULOOP technology, where it is important to discriminate between rational (and therefore selfish) and altruistic users. In the second step we must understand stakeholders interests and possible actions. Lets assume that the ULOOP technology is being introduced without any (security) mechanism to enforce cooperation. While both users behavior can be assumed to be oppositional, their interest is the same, as they want their packets to be routed through the ULOOP network. Also they do not want to spend energy. The way how they pursue the latter goal, leads to their differing behavior,
http://www.uloop.eu/
because the selfish users will decide to save energy by not forwarding any traffic for other users while altruistic users, will do so, as it reduces the overall energy consumption. In the third step of the tussle analysis methodology we must evaluate the possible outcomes. Performing a game-theoretic modeling shows that only in quite specific settings, multiple rounds will lead to cooperative behavior of selfish users, where the chances for cooperation increase with the number of times that users interact. In most realistic cases however, the outcome cannot be considered stable (this is depicted using a blue circle with dotted outline which is placed in the middle but slightly downwards). 2nd iteration In the second iteration the stakeholders remain the same (1st step), but now we explore the possibility of selfish users deploying download managers to switch relays frequently (2nd step). Given enough altruistic users exist this means that they will be able to exchange enough traffic, thus they will have no reason to behave cooperatively. Therefore, if no incentive mechanisms are implemented by ULOOP the tussle evolution will reach a state in that selfish users frequently switch their relay, as they rapidly fall from grace, for not forwarding packets. This state is obviously not desirable/fair, as the percentage of forwarded traffic in the network will be marginal and completely done by altruistic users. This means that this state should be placed (3rd step).
Figure 7: Tussle Evolution for Traffic Forwarding with ULOOP
3rd iteration Given that altruistic have no way to react but leave the system, another stakeholder may get involved; the developer of the ULOOP technology. In order to overcome this situation ULOOP developers have four choices, where each is discussed at a time next. These choices are related to the security function and more specifically monitoring of users aspects (mostly behavior). Thus the stakeholders under study are the selfish users and the ULOOP operator (who has compatible incentives with the altruistic users). The first case is ULOOP operators not to employ any monitoring mechanism (assuming that at least one is available). This is the current situation and selfish users expected actions would be the same as in the 2nd iteration. Thus, this state can be considered in favor to selfish users, but its not a stable one so it is depicted as a blue circle. The second case is to incentivize users to cooperate by rewarding cooperation. With respect to transmission, it will lead to a fair outcome, as rewards can theoretically be chosen so high that even for selfish users decide to cooperate [6]. However, a drawback is that by compensating users, only positive but no negative feedback can be given, which is why still not every user might choose to cooperate. Furthermore this solution also generates a spillover from the transmission function to the monitoring function, which is part of security: this spillover arises from the fact that rewards have to be paid by some entity, which will likely have to be the ULOOP operator. In this case, the tussle has been resolved in a fair manner for the transmission function, but clearly not in a fair manner with respect to the security function. The third case is to introduce incentive mechanisms by implementing a reputation system. As argued in (Sections A.5.1.4 and A.5.1.5 of [6]) this will also lead to high cooperation rates and therefore to a good and possibly stable tussle solution with respect to transmission function. What is more, is that it has high potential to lead to a fair state within the monitoring function: because the reputation system would be implemented by the ULOOP nodes themselves, the burden of running according mechanisms would be evenly distributed. This makes this approach preferable compared to the rewarding mechanisms. This advantage also becomes evident in Figure 7, where the circles of both solutions are centered for the transmission function (both are fair) but only the circle according to the reputation solution is centered within the monitoring function rectangle. Node that all four circles are tagged with question marks, as the real-world outcome highly depends on how according mechanisms are implemented and the evidence for their efficiency is currently only backed up by theoretical arguments. The fourth alternative is to provide incentive for cooperation by announcing the percentage of cooperating users for a specific ULOOP network. The idea is that even selfish users might be charmed into cooperation if the percentage of cooperating users is high. However, game theoretic modeling shown that this is not expected to affect the behavior of selfish/rational user at all. Therefore, such mechanism will not lead to better outcome with respect to the transmission function.
5. Conclusions
Following the design for tussle principle, the SESERV project aimed at identifying, discussing and disseminating key (socio)-economic issues related to FI technologies, which affect the interests of affected stakeholders, their chances of adoption, as well as, their effects on other Internet technologies. Therefore, SESERV has developed a methodology for analyzing and assessing the importance of socio-economic tussles in the Internet. In order to further increase the awareness of technologists about fundamental economic issues such as prevalent tussles and the risks of not taking them into account when designing new technologies, and to demonstrate how those ideas could be applied by learning from related case
studies, SESERV has further evolved this methodology to a top-down stakeholder and tussle analysis methodology. This framework encourages and guides technology developers in identifying the stakeholders of the technologies under development/ investigation, their interests and assessing whether these would be met with a particular implementation of each such technology. This whitepaper provides a detailed description of the tussle analysis methodology and describes a case study in order to answer two fundamental questions: Why tussle analysis should be used? and How tussle analysis should be used?. Regarding the first question, the benefits are two-fold: Designing a technology in a more holistic way, by taking into account the interests of major stakeholders early in the process, would lead to more sustainable socio-economic outcomes and increase the chances of that technology being adopted in the long-term. Furthermore, systematic investigation of how tussles are expected to evolve, by using the existing and suggested technologies, can provide useful insight to policy makers and technologists in identifying the most critical research areas for the Future Internet architecture.
In order to answer the second question we provided a detailed description of each step in the tussle analysis methodology. This includes a set of taxonomies: a) An extensive taxonomy of Internet functions which covers both aspects of how services are being hosted (cloud-related) and their actual delivery (network-related). b) A generic classification of Internet stakeholder into seven high-level stakeholder roles, where each one is further decomposed into more detailed instances. Furthermore, we describe candidate techniques for performing each of the steps, give recommendations and apply the tussle analysis methodology using a case study from the area of collaborative networking.
6. References
[1] Clark, D.D., Wroclawski, J., Sollins, K.R., Braden, R.: Tussle in Cyberspace: Defining Tomorrow's Internet. IEEE/ACM Transactions on Networking, Vol. 13, No. 3, pp. 462- 475 2005. [2] K. Kilkki: Sensible Design Principles for New Networks and Services. First Monday, Vol. 10, No. 1, 2005. [3] Kalogiros, C., Courcoubetis, C., Stamoulis, G. D., Boniface, M., Meyer, E. T., Waldburger, M., Field, D., and Stiller, B.: An Approach to Investigating Socio-economic Tussles Arising from Building the Future Internet. In The Future Internet, John Domingue, Alex Galis, Anastasius Gavras, Theodore Zahariadis, and Dave Lambert (Eds.). Springer-Verlag, Berlin, Heidelberg pp. 145-159, 2011 [4] The SESERV Coordination Action: Second Year Report on Scientific Workshops. SESERV Deliverable D1.4, 2012. [5] The SESERV Coordination Action: First Report on Economic Future Internet Coordination Activities. SESERV Deliverable D2.1, September 2011. [6] The SESERV Coordination Action: Final Report on Economic Future Internet Coordination Activities. SESERV Deliverable D2.2, September 2012. [7] The SESERV Coordination Action: Focus Group Methodology. SESERV Deliverable D1.5, August 2012. [8] Thi-Mai-Trang, N.: On the Way to a Theory for Network Architectures. World Computer Congress, Network of the Future Conference, Brisbane, Australia, September, 2010
[9] Godet, M.: Actors Moves and Strategies: The MACTOR Method, Futures, pp. 605-622, 1991. [10] Godet, M.: From Anticipation to Action. A Handbook of Strategic Prospective, Unesco Publishing, Paris, France, 1994.

The Tussle Analysis Cookbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Tussle Analysis Cookbook

Uploaded by

Copyright:

Available Formats

The Tussle Analysis Cookbook

Seventh Framework CSA No. 258138

Socio-Economic Services for European Research Projects (SESERV)