A SESERV methodology for tussle analysis in Future Internet technologies - Introduction and motivation

Editor's Notes

• #3: Internet is a platform which can be studied as a system composed of multiple technologies and an environment where multiple stakeholders interact in multiple ways (either by using or not technologies). At the socio-economic layer stakeholders have interests and incentives, expressed by making choices governed by laws of economics (e.g. supply and demand), politics, sociology, etc. that affect the technology layer.Such choices refer to what specific technologies will be introduced, how these will be dimensioned, configured, and finally, used. These collective decisions, together with the laws of physics, will determine how technology components will operate and produce outputs.For example the DNS (Domain Name System) associates domain names to network addresses in a distributed way, based on each administrator’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 delivery of services and content to end-users. Technology outputs are assessed by each stakeholder individually and can affect existing real-world interactions or trigger new ones (payments, friendship, price competition, price regulation, etc.)
• #4: When adding a new functionality in the Internet, it is natural that some stakeholders have conflicting interests when making technology decisions.The long-term goals of each stakeholder with respect to a specific Internet functionality define its strategy which is, finally, implemented by policies.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 functionality in questionDimension dedicated resources to support the goals of the stakeholderConfigure parameters of the technology that affect how functionality in general is providedConfigure parameters that affect how functionality for a specific instance is provided This process defines a “tussle” between the stakeholders, since they have in general conflicting goals.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 filed) set priority for queued files based on popularityISPs may: measure the performance of web-browsing connections and observe that these obtain a small bandwidth shareadd capacity to alleviate the problemIn general, policies are applied in a sequence similar to the one presented above and may adapt using feedback from the evolution of the system. The timescales that such relatively minor adaptations (they don’t affect the basic technology and socio-economic context of the tussle) take place depend on the social and technical “inertia” of the system and the given technologies. Eventually we expect this to lead to a tussle outcome, which is characterized by the benefit that each stakeholder gets (defined by appropriate utility functions at the socio-economic layer). These benefits can vary substantially between stakeholders and different concepts of fairness may apply depending on the social context.What we defined so far is the structure of the basic cycle. As we will see next, if the given outcome is not stable, we expect it to trigger a new tussle cycle to take place, where some more radical changes take place in the space of the adopted technologies. We must emphasize to the reader that sometimes this separation of the socio-economic technology evolution into distinct cycles is not so clear, since cycles themselves may include some degree of technology adaptation. Many times it is a matter of judgment to define the boundaries between cycles and the corresponding tussle outcome for each cycle. Nevertheless we believe that such a process helps the analyst understand the complexity of the underlying system and predict its evolution.
• #5: According to our previous discussion, tussle can be described as a process determined by the strategies of involved stakeholders to resolve their conflicts of interest in a particular technology context. We assumed that a tussle, after some adaptation from the stakeholders involved, leads to some outcome. In analogy to game theory, a tussle corresponds to a game where agents are the stakeholders in the given context. The outcome of the tussle may be a Nash equilibrium of the game. Our model of the Internet ecosystem assumes that tussles may evolve over time. Evolution occurs either because of instability or because of externalities.If the tussle outcome is considered “unfair” by a subset of stakeholders, it can evolve into a new tussle based on: socio-economic decisions alone (e.g. stop using that functionality, stop doing business, etc.), out-of-band actions (asking a regulator to intervene) or new socio-techno-economic decisions following the basic socio-economic technology cycle (introduce a radically different technology, new stakeholders enter the stage, etc.)All these reactions characterize an unstable tussle outcome.It is likely that unstable outcomes will lead to a new tussle and possibly destabilize other functionality spaces as well (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 anticipated before, which interfere with other functions of the ecosystem.We believe that analyzing the anticipated tussles can shorten unstable periods & help the long-term success of a technology.
• #6: This slide 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 observed to be in a stable state. At some time T1 both tussles A1 and C1 (for Functionalities A and C respectively) reach equilibrium, but only the latter is a stable one. Furthermore, the unstable outcome of tussle A1 has a spillover effect and triggers a new tussle B1 in functionality B. At some later time T2 both tussles A2 and B1 have reached equilibrium. Even though Functionality A has now reached a new and stable outcome, it has a spillover to functionality C and makes the previously stable outcome of C1 unstable. Thus, the tussles of functionalities B and C evolve further in time (not shown).
• #8: 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 controlling how bandwidth is being shared can be considered fair in the sense that if k connections are instantaneously active in a bottleneck link, then each of them would take 1/k of the bandwidth .But this outcome cannot be considered stable, after the introduction of peer-to-peer applications for file sharing.Users of such applications (called Heavy users) can open multiple TCP connections for the same file and get disproportionate bandwidth share in relation to traditional users (called interactive).This new outcome cannot be considered stable since the ISPs’ ability to offer other services was threatened by the greatly increased traffic.ISPs introduced middleboxes (dedicated machines that Deep Packet Inspection techniques for inspecting data packets) in order to identify and throttle peer-to-peer traffic.Even though this new bandwidth allocation outcome can be considered fair, it is not stable either.Peer-to-peer applications started 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 an ISP’s attempt to degrade quality of third-party VoIP services that threatened its traditional telephony services.This is an example of a spillover to another functionality, which was solved by asking the Regulator to intervene.Tussle analysis would try to understand the impact that a newly deployed technology (or set of technologies) would have on the stability of the tussle outcome for that particular functionality, 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 and congestion pricing schemes?The former technology (for example CONEX) would inform all parties along the path about the congestion that a packet would experience/cause.The latter technology would charge users based on the congestion they cause.Would the deployment of this technology set:a) lead to a stable outcome?b) create spillovers to other functionalities (e.g. routing)?
• #9: This slide gives a high-level view of tussle analysis methodology. Each step is shown as a horizontal 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 Slide2 for each particular functionality. Starting from the top of that figure identifying and studying the properties of the most important stakeholder roles is necessary. Besides recognizing the set of stakeholder roles their characteristics must be understood. The most important attribute of a role is the incentive to use this functionality. Finally technologies (complementary or substitute ones) that can be used for a service or application instance related to that functionality must be specified. These technologies, or technology sets, usually follow 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 conflict of interest is found to exist between some stakeholders, we should seek for policies – enabled by thetechnologies – that these rational entities would select in order to meet their goals. Thus, this step is about instantiating Slide3 in the specific context of this functionality.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 a diagram like the one in Slide5. In the ideal scenario of a tussle outcome is an equilibrium point, where: a) all stakeholders of this functionality derive a fair 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 this tussle equilibrium has been reached.If both conditions hold then the analysis of this particular tussle is completed and we can move on to the remaining tussles identified in Step2. In case condition (a) is not met, a new iteration of the methodology must be performed by making assumptions on the most probable policies adopted by unhappy stakeholders. Similarly, a new iteration must be performed for each spillover to other functionalities when condition (b) is not met.
• #10: The following questionscan act as a guide in performing the tussle analysis:[Q1] Understand stakeholders’ interests in current ecosystem: Translating Slide2 into your context, which functionality/functionalities does your proposed technology performs and what are the interests of the main stakeholders?[Q2] Understand stakeholders’ interests in new ecosystem: Repeat all steps of Q1, if your technology is deployed.[Q3] Identify policies in current ecosystem: Using Slide3 for the desired functionality, can you identify the most probable policies of each main stakeholder enabled by existingtechnologies (if your technology is not deployed)?[Q4] Identify policies in new ecosystem: Repeat all steps of Q3, if yourtechnology is deployed.[Q5] Assess current ecosystem: Translating Slide5 into your context, can you foresee the stability of existingtussle outcome and potential spillovers to other functionalities, if your technology is not deployed? What about expected efficiency?[Q6] Assess new ecosystem: Repeat all steps of Q5, if yourtechnology is deployed.The SESERV project performs a survey about the technologies proposed by FP7 projects and the associated socio-economic issues that already exist or would appear after the deployment of those technologies.We would be happy to receive your project’s response on the questionnaire.These answers can be qualitative.If you are interested we could organize a 30 min. audio-conference
• #15: Provide examples