Introducing and applying a SESERV methodology for analyzing socioeconomic tussles to the ETICS approach for providing QoS-enabled inter-domain services

8/3/2019 Introducing and applying a SESERV methodology for analyzing socioeconomic tussles to the ETICS approach for pro…

http://slidepdf.com/reader/full/introducing-and-applying-a-seserv-methodology-for-analyzing-socioeconomic-tussles 1/27

Introducing and applying a SESERV methodology for analyzing socioeconomic tussles to the ETICSapproach v1.0 Seventh Framework CSA No. 258138

Public

Socio-Economic Services for

European Research Projects (SESERV)European Seventh Framework Project FP7-2010-ICT-258138-CSA

Introducing and applying a SESERV methodology for analyzing socioeconomic tussles to the ETICS approach for

providing QoS-enabled inter-domain services

The SESERV ConsortiumUniversity of Zürich, UZH, SwitzerlandUniversity of Southampton, IT Innovation Centre, U.K.Athens University of Economics and Business - Research Center, AUEB-RC, GreeceUniversity of Oxford, UOX, U.K.Alcatel Lucent Bell Labs, ALBLF, FranceAtoS Origin, AOSAE, Spain

© Copyright 2011, the Members of the SESERV ConsortiumFor more information on this document or the SESERV support action, please contact:Prof. Dr. Burkhard Stiller Universität Zürich, CSG@IFIBinzmühlestrasse 14CH—8050 ZürichSwitzerland

Phone: +41 44 635 4355Fax: +41 44 635 6809

E-mail: [email protected]

© Copyright 2011, the Members of the SESERV Consortium




Public

Document Control

Title: Introducing and applying a SESERV methodology for analyzing socioeconomictussles to the ETICS approach for providing QoS-enabled inter-domain

services

Type: Public

Editor(s): Costas Kalogiros

E-mail: [email protected]

Author(s): Costas Kalogiros (AUEB), Costas Courcoubetis (AUEB), George D.Stamoulis (AUEB), Manos Dramitinos (AUEB)

Doc ID: ETICS-WP-v1.0.doc

AMENDMENT HISTORY

Version Date Author Description/Comments

V0.1 Jun 29, 2011 Costas Kalogiros, Costas Courcoubetis,George D. Stamoulis, ManosDramitinos

Draft version

V0.2 Jul 1, 2011 Brian Pickering Comments added

V1.0 Oct 23, 2011 Costas Kalogiros Details on Tussle analysis added, Updates to case studies

Legal NoticesThe 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 useof this material.





Public

Table of Contents

Introducing and applying a SESERV methodology for analyzing socioeconomictussles to the ETICS approach for providing QoS-enabled inter-domain services............................................................................................................................1Executive Summary ...................................................................................................... 4

1. A SESERV methodology for tussle analysis and evaluation ........................................ 61.1. Introduction and motivation ................................................................................ 6

1.2. Socio-economics driving the technology cycle .................................................... 71.3. Tussle evolution ................................................................................................... 81.4. A case study for bandwidth sharing with TCP .................................................... 101.5. A tussle analysis methodology .......................................................................... 111.6. The “Design for Tussle” goal............................................................................. 151.7. Relation to other approaches ............................................................................. 16

2. Introduction to the ETICS system ............................................................................. 183. Case study A: ASQ good and transit competition ..................................................... 204. Case study B: Customer SLA monitoring & incentives for backup ASQ provisioning 245. References ............................................................................................................... 27





Public

Executive Summary There is a consensus that, as the Internet has evolved from a highly controlled research network to

a worldwide social and economic platform, many initial assumptions about the motivation and thebehaviour of users and providers are no longer valid. The Internet has become a parallel digitaluniverse with social and economic linkages of online digital activities to their counterparts in thereal world. Thus, conflicts can emerge in digital interactions that are similar to those in a society or in the economy.

For example the DNS (Domain Name System) that associates domain names to networkaddresses in a distributed way based on each administrator’s configuration is increasingly beingused by ISPs for providing advertising services. More specifically the ISP will return a web-pagewith links to other related sites in case the URL (Uniform Resource Locator) typed by an end-user does not exist. This behaviour has been reported [5] to cause anomalies to programs, such emailclients, that would expect a different response.

Clark et al. [1] use the term “tussle” to describe such conflicts of interest between stakeholders.The SESERV project has described a methodology for analyzing and assessing the importance of socio-economic tussles in the Internet [2]. Tussle analysis concerns:

1. analyzing possible outcomes of the "technology cycle" with respect to stability andpossible spillovers, and

2. proposing some ways to correct such potential flaws (using the design for tussleprinciples).

So tussle analysis is very much related to the technology proposed, and is not just a statementabout the economic processes, like competition between providers of the same functionality. In

simple terms, economic competition is always in the background, but the tussle is the specifictechnology-enabled strategic behavior.

The purpose of this paper is to apply this methodology using as a case study an FP7 Europeanresearch project in order to clarify how each step may be executed and what its value might be incomparison to other similar methodologies, such as value network analysis. We selected theETICS1 project to apply this methodology, which enriches the current Internet model with inter-carrier assured-quality services, because it combines technological advances with socio-economicchallenges. In future this methodology will be applied to other representative research projects aswell, trying to cover several thematic areas of FP7 Challenge 1 (with main focus on Networks of the Future).

We apply the proposed tussle analysis methodology to two types of functionality offered by theETICS framework. The first one is related to establishment of QoS-aware, inter-domain paths andwe find that allowing fine-grained control over major properties of interconnection agreement (suchas set of IP destinations) can help adoption of the ETICS system and sustain a healthy ecosystemfor all participants. The second functionality investigated is service delivery with assured qualitybetween multiple ISPs and we find that even if ISPs are honest in primary paths they mayoverbook backup paths, thus without adequate monitoring it is not possible to correctly assignresponsibility for breaking the e2e SLA in case of failure along the path (where the backup shouldbe used).

The analysis performed is primarily based on the draft ETICS architecture and more specificallythe deliverables D3.2 “Potential business model analysis and requirements” [3] and D4.2 “Draft

functional definition of the elements of the architecture” [4]. Furthermore, this analysis is meant to1 https://www.ict-etics.eu/





Public

be indicative and not exhaustive. This means that part of the ETICS functionality has beenincluded and a subset of all potential tussles have been explored.





Public

1. A SESERV methodology for tussle analysis and evaluation

1.1. Introduction and motivation

Internet is a platform that can be studied as a system composed of multiple technologies and anenvironment where multiple stakeholders interact by using those technologies. This makes Internetinteresting not only to technology developers but economists and social scientists, as well.

Figure 1 depicts Internet as a two-layered platform. At the socio-economic layer stakeholders haveinterests, expressed by making choices governed by laws of economics (e.g. supply and demand),sociology, psychology, etc. Such choices affect the Internet technology layer by specifying thetechnologies to be introduced, how these will be dimensioned, configured, and finally, used.

Then all these collective decisions will determine how technology components will operate and

produce outputs that are valuable for these stakeholders. For example the DNS (Domain NameSystem) associates domain names to network addresses in a distributed way, based on eachadministrator’s configuration of a 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 deliveryof services and content to end-users. Similarly, routers interconnected through physical linksforward 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 maybe, we can say that the stability of the routing system is, in turn, affected by several factorsincluding the mapping of addresses performed by the DNS.

Technology outputs are assessed by each stakeholder individually and can affect real-worldinteractions (e.g., payments, price competition, price regulation, collaboration) or trigger new

technology decisions. All these interactions allow the Internet to evolve and act as a livingorganism.

Figure 1: Internet as a platform for stakeholders’ interactions





Public

1.2. Socio-economics driving the technology cycle

It is natural that some stakeholders have conflicting interests when making technology decisions.As shown in Figure 2, the long-term goals of each stakeholder with respect to a specific Internetfunctionality define its strategy that is, finally, implemented by policies. These policies take into

account the technology restrictions and other stakeholders’ socio-economic aspects. The decisionscontained 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 functionality in question

• Dimension dedicated resources to support the goals of the stakeholder

• Configure parameters of the technology that affect how functionality in general is provided

• Configure parameters that affect how functionality for a specific instance is provided

This process defines a “tussle” between the stakeholders, reflecting their conflict of goals at thesocio-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 combinationof actors’ policies leads to a tussle outcome.

Figure 2: 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 the expected

download completion time (for instance by attempting to download from multiple sourcessimultaneously) and, of course, content availability,

b. select the upper and lower limits of the upload/download capacity for that application(based on its connectivity profile and other communication needs),

c. configure maximum number of TCP connections per downloaded file (based on homerouter’s processing capabilities), 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 asmall bandwidth share, and





Public

b. add capacity to alleviate the problem.

In general, policies are applied in an order similar to the one presented above and may evolveusing feedback from the history of the system. The exact order depends on the specific context;e.g., due to outsourcing, it can be easier for a service provider to dimension resources at the

desired level rather than reconfigure a technology to support a new policy. The timescales thatsuch relatively minor adaptations (that don’t affect the basic technology and socio-economiccontext of the tussle) take place depend on the social and technical “inertia” of the system and thegiven technologies. For example it may take some time for the stakeholders to experiment in usinga new technology to meet their objectives. Eventually the process is expected to lead to a tussleoutcome, which is characterized by the benefit or satisfaction that each stakeholder gets, definedby appropriate utility functions at the socio-economic layer. The level of benefit can varysubstantially 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 isassumed that all stakeholders agree on what constitutes a “fair” outcome.

So far the structure of the basic cycle is determined. As shown next, if the given outcome is not

stable, because it is considered unfair by certain stakeholders, then it is likely to trigger a newtussle cycle, where some other (possibly, more radical) changes take place in the space of theadopted technologies. We must emphasize to the reader that sometimes this separation of thesocio-economic technology evolution into distinct cycles is not so clear, since cycles themselvesmay include some degree of technology adaptation and/or common policies by a significantfraction of a stakeholder group. Many times it is a matter of judgment to define the boundariesbetween cycles and the corresponding tussle outcome for each cycle. Nevertheless we believethat such a process helps the analyst understand the complexity of the underlying system andpredict its evolution.

1.3. Tussle evolutionAccording to our previous discussion, a tussle can be described as a process determined by thestrategies of involved stakeholders to resolve their conflicts of interest in a particular technologycontext. It was assumed that a tussle, after some adaptation from the stakeholders involved, leadsto some outcome. In analogy to game theory, a tussle corresponds to a game where agents arethe stakeholders in the given context. The outcome of the tussle may be one of the possible “Nashequilibria” of the game. Our model of the Internet ecosystem assumes that tussles may evolveover time. Evolution occurs either because of instability or because of externalities. Study of suchevolutions is what makes tussle analysis more powerful than a game-theoretic model.

If the tussle outcome is considered “unfair” by a subset of stakeholders, it can evolve into a newtussle based on:

• socio-economic decisions alone, e.g., stop using that functionality, stop doing business,

• out-of-band actions, e.g., asking a regulator to intervene, making coalitions for takingcoordinated technology decisions, or

• new socio-techno-economic decisions following the basic socio-economic technology cycledescribed before, e.g., introduce a radically different technology, use a technology option inan unforeseen way.

All these reactions characterize an unstable tussle outcome. It is likely that unstable outcomes willlead to a new tussle and possibly destabilize other functionality spaces as well. This is called a“spillover effect”. It should be noted that stable tussle outcomes can also create spillovers to other functionalities, in case some users of the established functionality find some new uses of it, not





Public

anticipated before, which interfere with other functions of the ecosystem. These are cases of negative externalities (i.e. adverse effects) between different functionality spaces. Positiveexternalities may also appear, for example more resources become available to a functionality dueto the introduction of a more efficient technology to another related functionality. In the sequel,consequences of negative externalities are studied, unless explicitly mentioned.

Figure 3 illustrates how tussles can evolve inside a single functionality space or affect another functionality. Let us assume a discrete-time model and that initially only Functionality B is observedto be in a stable state. At some time T1 both tussles A1 and C1 (for Functionalities A and Crespectively) reach equilibrium, but only the latter is a stable one. Furthermore, the unstableoutcome of tussle A1 has a spillover effect and triggers a new tussle B1 in functionality B. At somelater time T2 both tussles A2 and B1 have reached equilibrium. Even though Functionality A hasnow reached a new and stable outcome, it has a spillover to functionality C and makes thepreviously stable outcome of C1 unstable. Thus, the tussles of functionalities B and C evolvefurther in time (not shown).

Figure 3: Tussle evolution due to instability and externalities

SESERV believes that analyzing the anticipated tussles can shorten unstable periods and help theadoption of a long-term successful technology and configuration. Tussle Analysis defines asystematic approach for understanding the impact of introducing new Internet technologies, bytrying to answer the following questions:

• Is a new technology needed today and why?

o What are the interests of existing stakeholders today?

o What options do existing technologies offer to stakeholders?

o What are the properties of existing outcome in terms of performance and stability?

• What would be the effect of a new technology to the ecosystem in the future?

o How would the interests of existing and new stakeholders be affected?

o How would the options of existing and new stakeholders be affected?





Public

o Can this technology help reaching a “fairer” outcome regarding this functionality, or

increase efficiency in case of an already stable outcome?

1.4. A case study for bandwidth sharing with TCP

Figure 4: Tussle evolution due to instability and externalities for the bandwidth sharing case study

Figure 4 shows the tussle evolution due to instability and externalities when using TCP for sharingthe bandwidth on a common link. Stakeholders appear on the left of each rectangle, while thevertical positioning of an outcome denotes whether it considered fair or not. For this reason weassume that a neutral stakeholder exists, placed near the middle of each rectangle, and we use awhite background colour to denote this. We selected this case study due to its recent popularity.We could perform this study for another famous tussle, namely the configuration of DNS Serversby ISPs to respond for non-existing web-pages and act as another source for advertisingrevenues, its evolution as well as consequences that has been examined by the InternetArchitecture Board (IAB) [5].

When TCP (Transmission Control Protocol) was proposed in the early 80s, it was assumed that

hosts would initiate a single connection for each session. The algorithm suggested for controllinghow instantaneous bandwidth is being shared can be considered fair in the sense that if kconnections are instantaneously active in a bottleneck link, then each of them would take 1/k of thebandwidth.

But this outcome cannot be considered stable, after the introduction of peer-to-peer applicationsfor file sharing. Users of such applications (called Heavy users) can open multiple TCPconnections for the same file and get disproportionate bandwidth share in relation to traditionalusers (called interactive).

This new outcome cannot be considered stable either, since the ISPs’ ability to offer other serviceswas threatened by the great increase of peer-to-peer traffic. ISPs responded by introducing

middleboxes for inspecting data packets. These dedicated machines use advanced technology(Deep Packet Inspection techniques) in order to identify and throttle peer-to-peer traffic.





Public

Even though this new bandwidth allocation outcome can be considered fair (under someassumptions related to the level of throttling), it is not stable either. Peer-to-peer applicationsstarted performing traffic obfuscation (e.g. by encryption) in order to decrease downloading time.

At the same time, DPI technology allowed ISPs to identify traffic that directly competes with

complementary services they offer. A famous example has been a US ISP’s attempt to degradequality of third-party VoIP services that threatened traditional telephony services offered by anaffiliate of the ISP. This is an example of a spillover to another functionality, which was solved byaffected users asking the Regulator to intervene for discouraging anti-competitive tactics. The“VoIP service delivery” functionality was assumed to start and finally reach a stable outcome inorder to keep the complexity as low as possible. In reality the situation can be more complicated.

Tussle analysis would try to understand the impact that a newly deployed technology (or set of technologies) would have:

a) on the stability of the tussle outcome for that particular functionality,

b) on the stability of outcomes for other functionalities (spillovers to existing or new tussles)

For example, what would happen if ISPs deployed congestion exposure technologies andcongestion pricing schemes?

The former technology (for example CONEX2) would inform all parties along the path about thecongestion that a packet would experience/cause. The latter technology would charge users basedon the congestion they cause.

Would the deployment of this technology set:

a) lead to a stable outcome regarding the bandwidth sharing functionality?

b) create spillovers to other functionalities (e.g. routing)?

More research may be necessary to provide solid answers to those questions, but a qualitativeanalysis of the anticipated tussle outcomes could give useful feedback to those who design anddevelop Internet technologies. Slightly adjusting the algorithmic behaviour of the targetedtechnology at design-time could prevent such unstable periods.

1.5. A tussle analysis methodology

SESERV project has defined a systematic approach for analyzing and assessing the importance of socio-economic tussles in the Internet. This methodology initially outlined in [2] and compared to

other related approaches in Section 1.7 can be useful when designing new Internet technologiesfor understanding the expected impact to the stability and efficiency of that particular functionalityspace and possible spillovers to other spaces. Selecting the features of a technology in a moreholistic way, by taking into account the socio-economic layer of, Figure 1 would lead to moreattractive outcomes and increase the chances of that technology to be adopted in the long-term.

The proposed methodology is the following:

1. Identify all primary stakeholder roles and their characteristics for the functionality under investigation.

2. Identify tussles among identified stakeholders.

2 http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-02





Public

3. For each tussle:

a. Assess the impact to each stakeholder (short-term, mid-term or long-term depending on thecontext);

b. Identify potential ways to circumvent and resulting spillovers.

For each new circumventing technique, apply the methodology again.

Figure 5: High-level view of tussle analysis methodology

Figure 5 gives a high-level view of tussle analysis methodology. Each step is shown as ahorizontal rectangle with arrows denoting transitions. All steps are applied in the context of one, or more, functionalities (rounded vertical rectangles) The first step suggests composing the socio-economic and technology layers of Figure 1 for that particular functionality. Starting from the top of that figure identifying and studying the properties of the most important stakeholder roles isnecessary. These stakeholders make decisions that affect the outcome or have a vested interest inthe outcome. We are interested in stakeholder roles instead of specific entities, even though thelatter can be useful for understanding the context. Figure 6 presents a synthesis and classificationof Future Internet stakeholder roles into 7 categories by SESERV [7].

For the rest document, we will refer to stakeholder roles when mentioning stakeholders, unlessexplicitly mentioned. The reason for this abstraction is that the same entity may take multiple rolesin a particular instance of that functionality, or take a single role that can differ across instances of that functionality. Besides recognizing the set of stakeholder roles their characteristics must beunderstood. The most important attribute of a role is the goal to be met through this functionality,even though differences on the intensity may exist depending on the technology literacy andexpectations, 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 tospecify the technologies (complementary or substitute ones) that can be used for a service or application instance related to that functionality. These technologies, or technology sets, usuallyfollow a different logic or may not even be designed for implementing this functionality.

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 conflictof interest is found to exist between some stakeholders, we should seek for policies – enabled by





Public

the technologies – that these rational entities would select in order to meet their goals. Thus, thisstep is about instantiating Figure 2 in the specific context of this functionality. To address this stepin a more systematic way, an initial set of tussle patterns was identified. These tussle patterns,described in more detail in [2] (including their relationship to situations that are well known in theeconomic 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 notenvisaged by the resource’s owner.

• Responsibility where an entity attempts to identify who should be accountable for an actionthat is against its interests when many actors are involved.

• Control where two or more actors have different views on how a set of complementaryresources should be combined.

Figure 6: Stakeholder roles in the Future Internet

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 functionality under investigation)and understand its effects on the stability of other functionalities. It thus can be depicted using adiagram like the one in Figure 3. In the ideal scenario of a tussle outcome is an equilibrium point,where:





Public

a) all stakeholders of that functionality derive a fair 3 payoff (thus no one will select another

policy) and

b) no stakeholder of another functionality, who was receiving a fair payoff before, gets an

unfair payoff after that tussle equilibrium has been reached.

If both conditions hold then the analysis of this particular tussle is completed and we can move onto the remaining tussles identified in Step 2. In case condition (a) is not met, a new iteration of themethodology must be performed by making assumptions on the most probable policies adopted byunhappy stakeholders. Similarly, a new iteration must be performed for each spillover to other functionalities when condition (b) is not met.

Ideally a new technology should lead to a stable outcome without spillovers to other functionalities.In case where no such improvement takes place, the technology designer should examine whether a change in the implementation details would lead to a better outcome. In respect to that, Section1.6 discusses how the Design for Tussle goal can be achieved by following the principles of “Design for choice” and “Modularize the design along tussle boundaries”, proposed by Clark et. al.

[1].

The tussle analysis method introduced in this section is of interest to European research projectssince one of the key findings made from the SESERV Oxford workshop shows that “many of theprojects interviewed focused solely on direct controlling parties, those providing the funding,regulators and the consortium partners themselves. This means that some relevant considerationsare missed, not least in considering the specific impact of the technology on those who will use or be affected by it.” The tussle analysis method constitutes a suited tool for research projects to doexactly that, namely to assess socio-economic dimensions in a structured manner considering all stakeholders of relevance to the technology a project develops or studies. This is in line withDewandre’s keynote speech in which she stated that “all stakeholders should engage” [6].

If both conditions hold then the analysis of that particular tussle has completed and we can moveon to the rest tussles identified in Step 2. If any of the conditions above does not hold then weneed to examine the specific tussle in some detail to establish what might be done to restoreequilibrium between the stakeholders involved. Technologies proposed by research projects canbe designed towards this direction. In case condition (a) is not met, we must perform a newiteration of the methodology by making assumptions on the most probable policies adopted byunhappy stakeholders. Similarly, a new iteration must be performed for each spillover to other functionalities when condition (b) is not met.

Figure 7 gives a more detailed view of the tussle analysis methodology and the purpose of eachstep. Each purpose is depicted as a diamond while the colour determines whether that task refersto the present situation or a future ecosystem. Initially we apply the methodology for Functionality I,

based on the responses to the relevant questions, for a technology set S that covers existingtechnologies. 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 performanother iteration after the introduction of the proposed technology (technology set S’).

• If some stakeholders consider unfair the tussle outcome of Functionality II due to aspillover, then we have to perform an iteration for the technology set S’’, which includes theinitial technology set and the proposed technology.

3

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 differentparadigms such as social values vs. economic goals.





Public

Figure 7: A detailed view of tussle analysis methodology

1.6. The “Design for Tussle” goal

Ideally a new technology should lead to a stable outcome without spillovers to other functionalities.In case where no such improvement takes place, the technology designer should examine whether a change in the implementation details would lead to a better outcome.

Clark et al. [1] suggested that Internet technologies should be designed for allowing variation inoutcome and do not impose a particular outcome. The rationale behind the “Design for Tussle”goal is that Internet is a rather unpredictable system and it is very difficult to assess whether aparticular outcome will remain desirable in the future.

The tussle analysis methodology described previously helps in designing protocols that are

designed for tussle. A technology being designed for tussle, such as an Internet communicationprotocol, should:

• lead to a stable outcome by allowing all involved stakeholders to express their interests andaffect the outcome (“Design for Choice” Principle).

• avoid spillovers to other functionalities (“Modularize along the tussle boundaries” Principle).

The “Design for choice” principle provides guidance in designing protocols that allow for variationin 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 alsoconsider.





Public

• “Exchange of valuation” suggesting that the stakeholders involved should communicatetheir preferences in regard to the available set of choices (for instance by ranking them indescending order).

• “Exposure of choice’s 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 actionmust allow the inference of which of the available choices has been selected.

The “Modularize the design along tussle boundaries” principle helps in identifying whether tusslespillovers can appear. A protocol designer can check any of the following two conditions:

• “Stakeholder separation”, or whether the choices of one stakeholder group have significantside effects on stakeholders of another functionality (another tussle space), for examplecreates economic externalities between stakeholders of different tussle spaces.

• “Functional separation”, or whether different stakeholders use some functionality of thegiven technology in an unforeseen way to achieve a different goal in some other tusslespace, i.e., the functionality of technology A interferes (and possibly cancels) withfunctionality of technology B.

1.7. Relation to other approaches

We have already seen the objectives, rationale and steps of tussle analysis. We can summarizeour definition thereof as follows: Tussle analysis is a more complete analysis of the ecosystemwhere we analyse all potential conflicts and their interactions. It defines a framework, whichtogether with the “Design for Tussle” principles introduced in [1], can be used for designing Internettechnologies that balance technical and socio-economic objectives. The value of the analysis liesin providing some guidelines (principles) for identifying which aspects of the technology under testare responsible for poor tussle outcomes.

Table 1 provides a comparison of several approaches that can be employed in modelling of systems with interacting stakeholders, including value network analysis, risk analysis andassessment, and game theory. In particular:

• Value network analysis is a methodology for understanding and depicting actor relationships aswell as the processes that take place in dynamic and complex economic ecosystems in order to help identify what roles and interactions are needed to improve the overall effectiveness.

• Risk analysis is a method for identifying candidate factors that can have a negative effect on asystem and quantitatively or qualitatively evaluate those effects in order to take precautions.

• Game theory is a mathematical tool for finding and evaluating the possible equilibriumoutcomes of a specific scenario in a system with rational participants.

Value Networks Risk Analysis &Assessment

Game Theory TussleAnalysis





Public

Purpose Understandbusinessopportunities invalue creationdue to

technology

Understandvulnerabilities andeffectiveness of countermeasures

Understandoutcomes of multi-partyinteractions

Understandtechnologybottlenecks indealing withconflicts of

interest

Type of results

Empiricalassessment of opportunities

Empiricalassessment of risks andcountermeasures

Theoreticalassessmentof interactions

Empiricalassessmentof interactions

Interestscaptured

Competition for market share,Expansion toother/newmarkets

Threats fromcompetitors(intended) &random events(unintended)

Any Any

Actors’space

Very detailed(many actorsincluding their interactions)


Limited tomain actorsdue tocomplexity


Point-of-view Effects on singleactor

Effects on singleactor

Effects onmultipleactors

Effects onmultipleactors

Evolutionover time

Limited (ascreenshot is

examined,possiblereactions arenot explicitlydescribed)

Limited (ascreenshot is

examined,possible reactionsare not explicitlydescribed)

Multiplerounds of

actions arepossible

Multiplerounds of

actions arepossible

Interesting to Providers Providers, Policymakers

Policymakers,Providers

Policymakers,Providers,Vendors

Complexity Low Low High High

Table 1: Comparison of tussle analysis to other approaches for system modeling





Public

2. Introduction to the ETICS system

The ETICS project proposes a set of technologies and the associated economic mechanisms sothat participating providers can jointly offer premium connectivity services to their customers.These services to ETICS customers are provided by stitching connectivity agreements (calledAssured Service Quality (ASQ) agreements or goods) from several ETICS providers. The ETICSproducts are not just Best Effort connectivity products: they provide tangible Quality of Service(QoS) assurance in terms of reliability, bandwidth, delay, jitter etc over a certain ASQ path; thispath may be different than the path returned from Border Gateway Protocol (BGP) in order to meetthe QoS constraints demanded by the customer.

In a federated environment such as the ETICS marketplace, service composition is the process of establishing the end-to-end path and the technical parameters of the associated Service LevelAgreements (SLAs) between pairs of ETICS network operators. In order to do so, participantsmust be aware of the available services/products and all the necessary information (prices,availability, etc.), which takes places through a service discovery mechanism. Other types of functionality explored are admission control for service establishment and SLA monitoringmechanisms for collecting the necessary information during service provisioning to validateconformance to contract terms.

This new ecosystem gives incentives for ETICS Communication Providers to invest in new networkinfrastructure and extend their business model by offering advanced connectivity services in acooperative way, and for Information Providers to offer premium-quality services to their customers(such as stereo VoIP services offered by Communication Providers).

ETICS Communication Providers can be categorized based on their role during service

provisioning as “Edge Internet Service Providers (ISP)” who serve ETICS customers and “TransitISPs” who interconnect Edge ISPs. Several scenarios studied involve Brokers (called “Facilitators”)who provide supporting services to Edge and Transit ISPs, such as the catalogue of available ASQproducts.

The main ETICS customers are Service Providers (SP) that can be further decomposed based onthe type of traffic into Content SPs, Communication SPs, Application SPs and Online Gaming SPs.Furthermore, the uptake of cloud-enabled services has increased the interest of corporate andresidential customers for premium connectivity services.

Figure 8 below provides a simple example of a potential conflict within the ETICS ecosystem thatserves as an introduction to tussle identification and analysis. Suppose a specific SLA exists

between an end-user and ISP-1 governing the expected Quality of Experience (QoE) in terms of throughput and response time to a Content Provider. This customer-provider relationship appearsas a green solid line with diamond-shaped edges.

In ETICS individual service providers will typically maintain their own SLAs for the expected Qualityof Service (QoS) from one provider to the next. Such advanced interconnection agreementsdescribe the handling of traffic between providers (possibly for multiple ETICS customers) and thusexist in isolation from the QoE SLA governing the end-to-end (e2e) service. Furthermore, theseSLAs can refer to composite services of more than one ISP by stitching a set of atomic ASQgoods. In the ‘cascaded pull model’ scenario studied by ETICS, atomic ASQ goods are setup byeach ISP between border routers and advertised to their neighbours, who can possibly advertise itfurther.

In Figure 8 ISP-3 has created an atomic ASQ good with certain properties between its routers F,





Public

H. ISP-2 who learned about that specific interconnection service offer decides to use it together with a local ASQ good between routers C, D and disseminate this new composite ASQ-good toISP-1. Thus ISP-1 can reach through ISP-2 and ISP-3 the Content Provider and serve thecustomer’s request for premium connectivity.

Two SLAs will be created for this end-to-end service at the ETICS marketplace (shown as bluesolid lines with diamond-shaped edges); one among ISP-1 and ISP-2 for the path between C & Hand another one between ISP-2 and ISP-3 for a path between F & H. Both ISP-2 and ISP-3 willhave to manage their network so that all SLAs are honoured, for instance select one out of manyintra-domain paths available to route that particular traffic. Furthermore, ISPs usually interconnectat multiple locations for more routing options and increased reliability.

Figure 8: A scenario of premium interconnection services under the ‘distributed pull’ coordinationmodel

Suppose now that there is a failure of some kind on the network of ISP-2. Typically, failover will becatered for and the service can continue across any backup path. However, before the recoverycompletes, the end-user may notice degradation in the quality of the service provided by their ISPand the QoE SLA could have already been violated.

The question now is who should be held responsible for the failure? Without sufficient monitoringas well as cross-checking between all pairs of interconnected ISPs (ISP-1, ISP-2 and ISP-2, ISP-3), it is not clear whether the delay in traffic forwarding occurs as the traffic leaves or arrives at the

respective service provider. What if the content provider experiences local network issues, as well?For ETICS, how are they to decide where to apportion blame? Tussle analysis can help identify,define and ultimately assess solutions to the problem.

In what follows we provide examples of using the tussle analysis framework in the context of ETICS to predict and analyze potential tussles. We also critique (where possible) the technologychoices that lead to poor tussle outcomes.





Public

3. Case study A: ASQ good and transit competition

The basic idea is that two competing Tier-2 Internet Service Providers may benefit by establishingan ASQ agreement appropriate for transporting and terminating each other’s (customers’) traffic,since this will allow more lucrative end-to-end (e2e) services requiring QoS to be provisioned. Thebasic conflict of interest in such an ETICS-enabled marketplace is improving the value of their service to their own end-customers and becoming more competitive in the provisioning of such e2eservices. An interesting observation is that if such an ASQ is established without the right controlsin place, then it may cause, as a side effect, a market failure for premium transit services.

The larger ISP who is directly attached to more content providers and hence can provide contentwith better quality to their customers (ISPs buying transit services) is concerned of losing thiscompetitive advantage and become just the same as any other ISP due to the ASQ thatinterconnects them. This might prohibit the large ISP establishing the ASQ even though it could bebeneficial for both during the first phase of the tussle evolution. We analyze this phenomenon andusing the principles for design for tussle (described in Section 1.6) show that if enough control isavailable in the definition of the ASQ agreement, then the effects of a spillover can be reduced andhence the ASQ agreement can function as originally envisaged.

Let us suppose that a large operator, called ISP-1, has attached the cache of a popular ContentProvider (such as YouTube) to its network and no financial transactions take place (peeringagreement). Furthermore it has a peering link with ISP-2, which allows them to exchange their customers’ traffic for “free”. A third operator, called ISP-3, buys transit connectivity from ISP-1 as aresult of the higher quality connectivity to the Content Provider. All ISPs have a number of endcustomers, but ISP-1 has the largest market share, followed by ISP-2.

Figure 9: A scenario for Internet connectivity market

The main set of stakeholder roles includes ETICS Communication Service Providers or ETICSISPs for short (mainly Tier2, Tier3 ISPs) and Content Providers. Other involved roles areconsumers of ICT services and Regulators. For brevity, we will concentrate on the first set of actors and stakeholder roles.

In today’s Internet peering links are usually under dimensioned. More specifically, ISP-1 has noincentive to upgrade the capacity of the peering link in order to maintain its competitive advantageover ΙSP-2 for communication providers that buy transit services. Thus, unless peered ISPs are





Public

perfectly symmetric in terms of volume exchanged and networking services supported, such atussle outcome - for example the service composition functionality – would not be reached.

Furthermore in current Best Effort Internet, ISPs try to improve the quality of the services offered totheir customers by performing traffic engineering. This means that the inability to compose network

services with QoS features has a spillover to the routing functionality, as Figure 10 shows. Morespecifically, ISPs will enter a loop of performing routing in a way that optimizes the peering linkusage4 in a selfish way. Thus introducing ASQ goods correctly can have a positive impact onstability of routing sybsystem.

Figure 10: A tussle evolution for the service composition functionality

Now let’s consider what happens in the network service composition functionality. Assuming in thistoy scenario a stable initial outcome (green circle with dotted-line border), then two possible casesare shown depending on what SLA properties can be configured.

In the first case an ASQ good is assumed to describe QoS-related properties only, like bandwidth,

delay, jitter, etc. If such an ASQ good has been setup between ISP-1 and ISP-2 then the former would increase the quality that its customers perceive when interacting with customers of the latter for services like video etc. Similarly, ISP-2 would get premium quality connectivity for both theContent Provider as well as the rest of ISP-1’s end-customers without increasing its cost. Thisgives him an advantage in competing with the ISP-1 for end customers. The reason is thatcustomers of ISP-3 can access a popular destination (the Content Provider) with similar qualityacross both transit providers ISP-1 and ISP-2. As we described above this tussle outcome is notdesired by ISP-1 and thus is not stable (shown as a blue circle).

One way for ISP-1 to deal with this tussle would be to stop offering that ASQ good and exchangetheir customers’ traffic through another – transit – provider (a Tier-1 one). In this outcome bothproviders would experience increased cost in relation to the initial state and would not be satisfied.

4 A classic example being the “hot-potato routing” case between 2 peered ISPs that are interconnected in

multiple locations.





Public

Similarly, ISP-2 would find it beneficial to peer with the Content Provider for free. If ISP-1 hadperformed this analysis before adopting the ETICS solution then, under certain assumptionsrelated to its effect on demand for other market segments, the expected Return-on-Investment(ROI) would not justify adoption.

In the second case a mechanism is introduced for determining the set of IP addresses serviced byan ASQ agreement. This would allow ISP-1, for example, to setup an ASQ agreement for theContent Provider’s range of IP addresses by asking a fee and another one for the rest of itscustomers for free. This is in line with the existing situation where peering links are not suitable for moving data sensitive to congestion effects. In this case, the actor who can compose an ASQproduct has more power in controlling its properties than those who have to buy it. This power canbe balanced by giving customers the ability to request the creation of an ASQ product on demand.It is important to note that in either case, the introduction of prices helps the parties involved to findan equilibrium that is fair for both of them (shown as a blue-bordered circle). Furthermore, aregulator would be asked to intervene should an anti-competitive tactic be identified5.

To illustrate this, let’s investigate further the consequences of introducing separate ASQ

agreements for different service attributes. Service attributes include destination IP prefix ranges,capacity, quality constraints and price. Suppose that the details of the ASQ agreement regardingthe Content Provider have been agreed. Now, ISP-1 and ISP-2 negotiate the details of the other ASQ agreement considering as a first option a reciprocal scheme (without payments). Assumingthat respective retail market share has not changed since the adoption of the ETICS solution byISP1, then ISP2 will be sending more traffic than it receives (otherwise the peering relationshipwould not be in equilibrium in the pre-ETICS period). In peering terms this means that the peeringtraffic ratio is not balanced. Thus operators would have to renegotiate the terms of the ASQagreement. It is important to note that they could find an equilibrium point (meaning that they wouldbe happy with the outcome) by configuring the service balance attributes alone, without the needto explore work-arounds.

Figure 11: The scenario for Internet connectivity market using ASQ goods

What is interesting is that the new outcome of the network service composition functionality has apositive impact on routing and traffic engineering functionality. The reason is that ISPs don’t haveto perform complex traffic engineering anymore to improve the QoE of their customers. This couldhave led to a stable outcome, but we expect that some ISPs with less spare capacity would still

5

We should note that the Content Provider will have deployed several caches around the world. This meansthat alternative paths will be available (for instance through a Tier-1 provider, which is not shown in the figureabove).





Public

rely on traffic engineering for meeting their SLAs. Thus, routing instabilities may still exist but theseshould have smaller impact on other ISPs.





Public

4. Case study B: Customer SLA monitoring & incentives for backup ASQ provisioning

SLA monitoring is the process of collecting the necessary information when services are beingdelivered, in order to establish conformance to contract terms. This functionality is considered tobe important even when trusted operators (as in the case interested in ETICS) must collaborate inorder to provide QoS-assured services end-to-end. This is because such premium transportservices are secured by SLA terms and can trigger payments to the customer in case some of theISPs in the ASQ path fail to meet its requirements. The existence of monitoring technology whennetwork operators offer services that are not under their complete control (since more than oneISP is involved) would lower their exposure to SLA violation assuming they have kept their commitments. On the other hand, the monitoring solution must be carefully designed in order tokeep capital and operating expenses low.

In this case study we look at another interesting implication of monitoring related to the reservationof backup capacity. Although not directly mentioned in the SLAs, ISPs are expected to keepbackup capacity available in case the original path used by the ASQ agreement has a failure point.If a failure occurs in its network, the ISP will need to reroute the traffic of the ASQ agreement whichmight cause a QoS degradation and hence an SLA violation. This can happen either because thenew path in his own network violates what is promised by the SLA, or because he directed thetraffic to some different ingress point of the next ISP in the path and this ISP had not been gearedto offering the appropriate QoS on this new path through their network (or both). Of course whether this happens depends on the amount of backup capacity available in the network of both ISPs.

Monitoring can help provide the right incentives for keeping backup capacity since it enables

finding the ISPs who can be considered responsible for the QoS failure. In simple terms, if noadequate monitoring is in place to identify the ISP who caused the rerouting and the QoS violation,then the penalty of the violation will be assigned to the service originator (the first ISP thatinterfaces to the customer of the ASQ agreement), or can be divided equally among the ISPs. Onecan easily see that at the equilibrium, ISPs will pick a strategy to provide minimal backup. There isobvious free-riding since the effects of low backup provisioning are shared among a large number of ISPs. By contrast, if we can isolate the cause of the failure, the appropriate ISP can be identifiedfor payment of the penalty, which pushes the incentives in the right direction.

So, in summary, the tussle here is related to responsibility: what technology decisions Internetstakeholders make that can lead to unfair allocation of SLA violation penalties? The aim is toidentify candidate technologies and their implementation details so that communication providers

have the incentive to honour their SLAs and, whenever this is not the case, violating parties to beidentifiable and contribute on a fair manner.

The ETICS project initially examined three candidate schemes for end-to-end metrics monitoring.A centralized one that assumes the presence of a trusted operator and two distributed schemes;one relying on the coordinated sampling of packets to be monitored combined with the ability for hierarchical access to this data, and the other based on the active flow technology which providesthe control of network devices to be handled programmatically. We will apply the tussle analysismethodology to the distributed hierarchical scenario, as the more likely to be deployed.





Public

Figure 12: A scenario of SLA violation identification using the hierarchical monitoring approach

Building upon the scenario of Figure 8, each ISP collects raw data by specialized border routers,called probes. In order to keep the operational cost tractable, data sampling is performed.Furthermore, sampling suggests that monitoring data stored by each ISP along the path refer tothe same packets; otherwise not all SLAs and their metrics (for example the end-to-end one-way

delay for short time contracts) may be checked. The monitoring data is stored at dedicateddatabases, called proxies, operated by each ISP to overcome confidentiality issues. In the case of an SLA violation ticket, a collector queries all relevant proxies and compares retrieved data inorder to check the validity of each SLA violation ticket. ISPs or trusted third parties can act asBrokers operating collectors.

The main set of stakeholder roles involves ETICS Communication Service Providers and morespecifically Edge and Transit ISPs. Other involved roles are Content Providers, consumers of ICTservices and Regulators. Again, for brevity, we will concentrate on the first set of actors andstakeholder roles.

Figure 13: A tussle evolution for ETICS Network Service Delivery functionality

Figure 13 shows a possible evolution of the tussle described above between a Transit ISP (ISP-2in our example) and Source, Destination ISPs (such as ISP-1, ISP-3 respectively). As long as BestEffort is the only traffic class available on the Internet, no SLA monitoring is needed and thus weassume that in the beginning we have a stable outcome (green circle).

The introduction of inter-domain ASQ goods by ETICS creates the need for backup paths that willbe used in case of a sudden failure. All ISPs however have the incentive not to announce sensitiveinformation such as network topology and dimensioning (including the backup paths). Furthermore,they tend to keep failover capacity low to avoid unused and therefore unbilled capacity. Thismeans that the new tussle outcome is not stable at the second phase, but no SLA violation has

been reported and thus the outcome is still fair.





Public

Suppose that the SLA between the transit ISP-2 and the destination ISP-3 allows occasionally theformer to dynamically reroute traffic to another ASQ agreement of the latter, involving another Point of Presence (POP). Furthermore assume that the interface used at the egress router of ISP-2 goes down due to some hardware failure, which affected its ability to continue using the sameASQ. The ISP-2, taking advantage of the respective SLA terms, reroutes Customer traffic to a

backup ASQ agreement, through router E. Now, ISP-2 manages to satisfy the QoS constraintsinside its network, whereas the ISP-3 fails to meet the terms of the SLA with ISP-2, because thebackup ASQ is not properly dimensioned. In absence of any SLA monitoring ISP-1 cannot infer whether it’s his responsibility or another ISP along the path (and even if he does he would havedifficulties in justifying its claims). Assuming that the Customer will issue an SLA violation ticket,penalties will be unfair (against ISP-1 in this scenario but both Edge ISPs on average). This couldlead to a market failure due to misaligned incentives; an increasing number of ISPs will have tolower their cost, having a negative effect on customer’s QoE and thus on demand for premiumservices.

Let us examine the case where a trusted third party (a broker) implements the hierarchical SLAmonitoring mechanism and ISPs agree to allow the collector to access data from their proxies.

Such a technology, together with an incentive mechanism for calculating a fair allocation of thecompensation to the ISPs, could lead to a stable tussle outcome. However, depending on theimplementation of the SLA monitoring mechanism identification may not always be feasible. Weidentify two cases for the SLA monitoring technology for illustrative purposes; a simple one and anadvanced one.

In the first case where sample packets were known in advance, Transit & Destination ISPs couldforward probing packets preferentially. Thus the responsible ISPs may not always be identified.This means that the total payments for made for customer SLA violation is analogous to thenumber of end-customers that ISPs have. Assuming that a Transit ISP has fewer customers thanan Edge ISP we can conclude that this tussle outcome is more beneficial to the former one.

Another case could be that Brokers signal to all ISPs along the path which packets to probe duringservice provisioning and they have to save a timestamp for those packets at the egress router.Following a secret algorithm for statistically selecting those packets, a Broker could make harder the expedite forwarding of sample packets only6, giving the right incentives for correctdimensioning of backup paths and lead to a stable outcome.

Once again, the tussle analysis methodology has highlighted potential solutions to an initialproblem, allowed us to assess what effect those potential solutions would have on those directly aswell as indirectly involved might be (the stakeholders) and thereby set out which solutions arepreferable in any given case. The methodology therefore allows for risks and potential antidotes tobe examined, as well as to cater for the interests of those not directly involved in the immediatecontested situation.

6

Other issues that should be considered are the integrity of data stored for the sample packets at proxiesand synchronization of routers’ clocks. An ISP, for example, could report biased data by subtracting fewmilliseconds from actual data.





Public

5. References

[1] Clark, D.D., Wroclawski, J., Sollins, K.R., Braden, R.: Tussle in cyberspace: defining tomorrow'sInternet, IEEE/ACM Transactions on Networking, Vol.13(3), pp. 462- 475 2005

[2] Costas Kalogiros, Costas Courcoubetis, George D. Stamoulis, Michael Boniface, Eric T. Meyer,Martin Waldburger, Daniel Field, and Burkhard Stiller: 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 145-159, 2011

[3] ETICS public deliverable D3.2 “Potential business model analysis and requirements”,https://www.ict-etics.eu/publications/deliverables.html

[4] ETICS deliverable D4.2 “Draft functional definition of the elements of the architecture”,https://www.ict-etics.eu/fileadmin/documents/publications/deliverables/D4_2_ETICS_architecture_and_ functional_entities_high_level_design.pdf

[5] IAB: Architectural Concerns on the Use of DNS Wildcards, http://www.iab.org/documents/correspondence-reports-documents/docs2003/2003-09-20-dns-wildcards/, September 2003

[6] N. Dewandre: The Societal Interface of the Digital Agenda for Europe, Keynote address at theOxford/SESERV Workshop, http://www.seserv.org/panel/conferences-webcasts#dewandre, 2011

[7] SESERV public deliverable D2.1 “First Report on Economic Future Internet Coordination Activities”,available at http://www.seserv.org/fise-conversation/annualreportonstudyingtheeconomicaspectsoffutureinternettechnologies

https://www.ict-etics.eu/publications/deliverables.html

https://www.ict-etics.eu/fileadmin/documents/publications/deliverables/D4_2_ETICS_architecture_and_%20functional_entities_high_level_design.pdf



http://www.iab.org/documents/correspondence-reports-documents/docs2003/2003-09-20-dns-wildcards/



http://www.seserv.org/panel/conferences-webcasts#dewandre



http://www.seserv.org/fise-conversation/annualreportonstudyingtheeconomicaspectsoffuture%20internettechnologies



https://www.ict-etics.eu/publications/deliverables.html









Documents

Introducing and applying a SESERV methodology for analyzing socioeconomic tussles to the ETICS approach for providing QoS-enabled inter-domain services