Using Focus Groups and Tussle Analysis Methodology For Understanding Socio-Economic Aspects of The Future Internet

Using Focus Groups and Tussle Analysis Methodology for Understanding Socio-Economic Aspects of the Future Internet 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
Using Focus Groups and Tussle Analysis Methodology for Understanding Socio-Economic Aspects of the Future Internet
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 2012, 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
Using Focus Groups and Tussle Analysis Methodology for Understanding Socio-Economic Aspects of the Future Internet v1.0 Seventh Framework CSA No. 258138
Public
Document Control
Title: Type: Editor(s): E-mail: Author(s): Doc ID: Using Focus Groups and Tussle Analysis Methodology for Understanding Socio-Economic Aspects of the Future Internet Public Costas Kalogiros ckalog@aueb.gr Costas Kalogiros (AUEB), Eric Meyer (OII), J Brian Pickering (IT Innovation), George D. Stamoulis (AUEB), Anne-Marie Oostveen (OII) FocusGroupWP-v1.0.doc
AMENDMENT HISTORY
Version
V0.1 V0.2 V0.3
Date
Oct 29, 2012 Nov 9, 2012 Nov 12, 2012
Author
Costas Kalogiros, J Brian Pickering, Anne-Marie Oostveen Costas Kalogiros Eric Meyer
Description/Comments
Draft version Minor changes Social recommendations added
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.
Public
Table of Contents
1. 2. Introduction..............................................................................................................................................................................4 Focus Groups: General Methodology .......................................................................................................................4 2.1. Rationale .............................................................................................................................................................................4 2.2. Focus groups....................................................................................................................................................................5 2.3. Running the Focus Groups ......................................................................................................................................5 2.4. Details of Group Composition.................................................................................................................................7 2.5. Should Focus Groups Involve Strangers or Pre-existing Social Groups?....................................7 2.6. The Stakeholders for the Focus Group.............................................................................................................8 2.7. Number of Groups.........................................................................................................................................................8 2.8. Recruitment .......................................................................................................................................................................9 2.9. Rle of Facilitator ...........................................................................................................................................................9 2.10. Choice of Venue .......................................................................................................................................................... 10 2.11. Audio and Video Recording .................................................................................................................................. 11 2.12. Length and Payment................................................................................................................................................. 11 2.12.1. Length .......................................................................................................................................................................... 11 2.12.2. Payment...................................................................................................................................................................... 11 2.13. Tools and Techniques.............................................................................................................................................. 12 2.13.1. Pre- and Post-Group Self-Completion Questionnaires ................................................................... 12 2.13.2. Presentation Material .......................................................................................................................................... 12 2.14. Discussion ....................................................................................................................................................................... 12 2.14.1. List of Issues............................................................................................................................................................. 12 2.14.2. Focusing Exercises .............................................................................................................................................. 13 2.15. Conclusions on Focus Group Methodology from SESERV ............................................................... 14 3. Introducing and Applying the Tussle Analysis Methodology...................................................................... 15 3.1. Tussle evolution ........................................................................................................................................................... 16 3.2. The tussle analysis methodology ...................................................................................................................... 18 3.3. Case study: Customer SLA Monitoring and Incentives for Backup ASQ Provisioning...... 23 4. SESERV Recommendations ...................................................................................................................................... 27 4.1. Economic SESERV Recommendations ........................................................................................................ 27 4.2. Social SESERV Recommendations................................................................................................................. 33 5. Conclusions.......................................................................................................................................................................... 38 6. References ........................................................................................................................................................................... 39 7. Abbreviations....................................................................................................................................................................... 41
Public
1. Introduction
Perhaps the most important finding out of the events and bilateral discussions that took place during the SESERV lifetime is the perceived need for cross-disciplinary debate to arrive at solutions, taking on board the issues and concerns of all affected parties within a common understanding of what those issues are. The development of key socio-economic challenges about the Future Internet is reported in deliverables D2.2 [5] and D3.2 [6]. But an important consideration is how we should arrive at such multi-disciplinary views without being constrained by the lack of common terminologies. Bringing participants technologists, social scientists, policy makers, end users - at the various events together to discuss relevant topics is one thing. Trying to bring together a group of such disparate interests within a common context (interest in the FI) and exploring how ideas or even solutions and recommendations could emerge is a challenge. However, one technique which could provide significant benefit in this situation is a focus group. As Kitzinger points out: [Focus groups] examine how knowledge and, more importantly, how ideas both develop, and operate, in a given cultural context Kitzinger [7] As such, focus groups seemed an ideal choice to facilitate discussion around these themes, whilst at the same time allowing for different stakeholders to come together in ways that they would not normally be accustomed to in pursuit of a multi-disciplinary approach to the major socio-economic concerns surrounding the future internet. Furthermore, focus groups have been identified as a very effective way for performing the tussle analysis methodology. This method is perceived to offer a structured approach for identifying, communicating, and addressing socio-economic aspects of Internet technologies. This method was applied in the context of 8 research projects and the examination of the 27 related tussles provided useful feedback to the Future Internet community [5]. The first part of this document sets out the background and approach to the use of focus groups in the context of Future Internet socio-economics, relates it to the tussle analysis methodology and provides guidelines to other researchers, technology makers and policy makers. Then, the tussle analysis methodology is introduced and applied to a case-study of the ETICS1 research project. Finally, a set of social as well as economic recommendations to Future Internet stakeholders is presented.
2. Focus Groups: General Methodology

2.1. Rationale
The purpose of these focus groups is to engage with appropriate stakeholders and explore their perceptions such that those building and those researching the FI might understand how stakeholders respond to the challenges faced. Engaging directly with them has enabled SESERV to establish any common perceptions, concerns and areas which require further investigation or effort. To this end, the project decided to organise a number of focus groups, recruiting attendees at a number of different events. As highlighted through the various project-led engagements, it has become clear that a true understanding of future socio-economic challenges can really only be
https://www.ict-etics.eu/
Public
gained through bringing together appropriately experienced players from diverse areas and encouraging discussion between them. Such cross-sectorial debate is what SESERV champions2,3 and which has already begun to highlight issues and challenges which have perhaps been lost in governmental instruments and reports.
2.2.
Focus groups
Using focus group discussions has become a key method for the collection of information of a qualitative nature. There are significant features of a focus group which need to be considered and which benefit the FI socio-economic debate: the aim is not (necessarily) to establish consensus or even common understanding. Instead, a focus group involves the dynamic evolution of a collective and possibly divergent view, using appropriate language and expressing thoughts and ideas as they come up during discussion, allowing ideas, concepts and vocabulary to be challenged immediately, and new trains of thought explored. As highlighted elsewhere, a common language for discussion is missing; and the need to bring together diverse stakeholders is key to moving the debate forward. Focus groups are ideally placed to facilitate such debate. Although the high profile accorded to the focus group in both market research and political canvassing is not matched within social research, it has a valuable rle to play in the generation of qualitative data. Recognition of that value has led in recent years to renewed interest in the use of focus groups in social research. Indeed, its origins lie within sociology [8]. In the 1950s the American sociologist Robert Merton and his colleagues [9] used focus groups, in combination with other research methods, to examine the impact of wartime propaganda [10]. Since then, a wealth of work in health and social integration has used focus groups extensively4. A focus group consists of a small group of individuals, usually between six and ten people5, who meet together to express their views about a particular topic defined by the researcher. A facilitator leads the group and guides the discussion between the participants. In general, focus groups last one and half to two hours and are recorded (video, audio, or both). The audio-recording can be transcribed for analysis. The focus group enables the researcher to explore participants views and experiences on a specific subject in depth, for example the use of the Internet for social or collaborative networking, or changing connection agreements between ISPs. In the normal course of a focus group participants will raise issues relating to the subject that the researcher might not have previously considered and comment on each others experiences and attitudes [10]. Focus groups provide an ostensibly attractive medium for public participation in the research process: they are social events; they are time-limited; and they require no technical skills from group members (Bloor et al [11]). For SESERV, public relates to the community of technologists, experts, policy makers and users within the FI ecosystem.
2.3.
Running the Focus Groups
The focus group literature has typically recommended groups consisting of between six and ten people as the optimum size for focus group discussion. However, groups have been reported that have ranged in size from as small as three and as many as fourteen or fifteen participants. For SESERV, group-size was dictated by the logistics of the background event. Exploring the user requirements for online Social Networking Sites (SNSs) for instance at a certain location where there are few SNS participants would necessarily define the limits of the size of the group. In

http://www.seserv.org http://www.seserv.org/fise-conversation/Outcome-of-the-SESERV-workshop-on-the-interplay-of-economics-andtechnology 4 There is a whole literature on nursing practices [16], socio-cultural attitudes [15] and AIDS [17] 5 Numbers do vary in the literature from small (3-8 participants) to moderate (5 to 15). As discussed in subsequent sections WP2 and WP3 decided on different approaches.
3 2
Public
addition, participant travel arrangements and their own networking requirements at larger events may dictate practical limits on group size. Whatever the size of the group it was felt important to try to balance the characteristics of participants as well as the topics being discussed. The basic guiding factor for group size resides with group dynamics. Larger groups can be more difficult to moderate, especially if subgroups form between individuals who may wish to ally themselves with participants having similar views. In a limited time period, the focus is on trying to allow everyone to have a chance to speak, rather than developing concepts in greater depth, with individuals being able to come in more than once and explore ideas together. In addition, of course, participants can feel threatened in larger groups especially if smaller subgroups have formed and the individual feels isolated or separated. In consequence, groups of smaller size tend to be successful in: Studies of sensitive behaviour, which would offer an opportunity to explore some of the more private areas of online identity, community membership and trust, and more sensitive areas of network management and traffic shaping; Studies with minority groups, which would provide a forum to consider the concerns of those that the Digital Agenda targets for inclusion, as well as those FI ecosystem stakeholders who may feel disenfranchised depending on how network contention is resolved; Complex topics, involving infrastructure, services, applications and user perceptions and ad hoc usage; Dealing with experts, who would form the majority of participants given the nature of the events; in smaller groups, individual experts will tend to discuss autonomously and from their own viewpoint, whereas in larger groups, there may be a tendency for those less experienced to unconsciously align themselves with perceived experts rather than voicing and developing independent views; Dealing with people in authority, which might help uncover practical disparities among stakeholders.
Groups consisting of a smaller number of individuals can potentially result in limited discussion and risk cancellation if just one or two participants fail to turn up. But as described above, larger groups can also present problems. They can be difficult to moderate and may frustrate the participants if they feel that they have not had adequate time to express their views and opinions. They may deteriorate with the more outgoing and vociferous members of the group dominating the interaction, whereas in smaller groups it is easier for the moderator to intervene. In purely practical terms, the more participants, the more difficult it becomes for the transcriber to attribute sets of interaction to specific individuals. The SESERV focus groups reported on in different deliverables were organised principally in association with appropriately themed events for FI stakeholders, including technology providers as well as social scientists and experts, and users where possible. The demographics of attendees at such events can be seen as potentially limited: are all stakeholders represented, for instance? However, there is a key advantage in as much as participants at these events will tend to be significantly more motivated in exploring specific issues than a wider, more general audience. For SESERV, this offers the potential for focused and relevant discussion from the outset, which means we avoid having to organise a number of iterations for a single focus group to encourage group cohesion as well as helping to home in on topics of real common interest. WP2, with its emphasis on economic issues within the network and its direct engagement with Challenge 1 projects and tussle analysis, decided to examine potential tussles in their focus groups. They engaged with the major FI ecosystem stakeholders in an attempt to elicit their views on what is needed within the Future Internet, as well as to discuss potential problems that would need to be addressed. The basic approach to the FGs was to seed discussion with a presentation from one of the various Challenge 1 projects describing a particular tussle and then investigate
Public
how discussion would pan out across the multiple stakeholders involved: a real-time tussle analysis initiated via technology presentation. Those organised in association with the SESERV Athens Workshop6 and the FIA Aalborg event typically involved 10 to 15 participants, each representing an FI ecosystem stakeholder. For WP3, by contrast, there was no attempt to steer discussion in a similar way; tussle analysis does not apply so readily to the broader social issues identified during the SESERV project, and the distinction between FI stakeholder and FI participant is less well defined. As with the SESERV Oxford Workshop breakout sessions7, there was no particular need to suggest or assign stakeholder rles; those taking part engage at a whole number of different levels including from the perspective of their research and project experience as well as from their own observations of the way in which the FI is developing. Further, the WP3 focus groups tended to be smaller, less constrained discussions of 4 to 8 participants.
2.4.
Details of Group Composition
Attention must be given to participant characteristics in relation to the topic being discussed and effort and thought to recruitment sources and strategies (Bloor et al [11]). 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. Researchers should also be aware of differentials between participants that may cause some views to be silenced, for example, groups where individuals vary in status and in power. WP2 and WP3 adopted different approaches. For economic topics, network researchers and service providers tend to form a fairly homogeneous set in terms of experience though have very different economic interests and concerns. It may be that inviting them to assume stakeholder rles may force them into specific position-taking, which in itself is an interesting subject of investigation. By contrast, and since societal topics identified for the FI are not generally regarded as particularly sensitive, WP3 could accommodate more heterogeneous groups. In the end, participants in both economically focused or societally focused groups were selected as representative of a range of rles and views with appropriate interest and experience across a wide variety of areas all related to the FI and Challenge 1 technologies as could be found at the various background events.
2.5. Should Focus Groups Involve Strangers or Pre-existing Social Groups?

From the literature on focus groups we learn that research participants who belong to pre-existing social groups may bring to the interaction comments about shared experiences and events and may challenge any discrepancies between expressed beliefs and actual behaviour and generally promote discussion and debate (Bloor et al. [11]). Pre-existing groups can also have major practical benefits. Recruiting a group that is part of an established social network can reduce recruitment effort because the researcher can contact group members through one individual group member. It is also possible that pre-existing groups may result in reduced attrition rates because the participants have a sense of shared obligation to attend (in contrast to a group of strangers). One problem with pre-existing groups is over-disclosure. Spur of the moment disclosures about issues or events unknown to other group members may have an impact upon everyday relationships after the group is over. Focus groups of strangers may potentially have the additional advantage of allowing people to speak more freely and openly than they would in a pre-existing social group without the fear of repercussions after the group is over. However, groups of strangers may be less cohesive than those consisting of individuals with pre-existing social links. They may take more time to warm up:

6 7
http://www.seserv.org/athens-ws-1 http://www.seserv.org/panel/Cross-thematictrendsofbreakoutsessions.pdf
Public
this is where focusing exercises can be a great help. Another problem is that strangers are less likely to attend the group. Because of the nature of SESERV topics, and of participation at the targeted events, it was felt that participants would of necessity fall into a hybrid category: they are not or rarely friends or other social group members, and yet they are also not entirely strangers, since they share a common interest in and experiences with the subject matter. For SESERV, the idea was to get as many appropriate stakeholders involved as possible. WP2 in Athens explicitly assigned stakeholder rles to participants to encourage their input from a specific viewpoint. By contrast, WP3 invited participants at random from the various delegates at the background events. In so doing, the two work packages had different levels of facilitation to deal with: for WP2, it was very much a classic moderator position maintaining some degree of equal participation across the FI stakeholders represented, though all participants could be expected to have the same level of familiarity with the subject matter. WP2 was therefore about exploring opposing views and investigating conclusions. By contrast, for WP3, the task was to encourage discussion across participants with differing interests and levels of experience with the FI and thereby explore the formation of ideas and concepts.
2.6.
The Stakeholders for the Focus Group
The topics for discussion involve stakeholders across FI technologies and areas of expertise. Ideally, the focus groups would therefore consist of participants of different: Areas (network, end-users, applications, services, etc) Involvement types (technologist versus scientist, and so forth) Experience with the FI Experience with the different EC instruments of relevance Exposures to end-user services
We had to be realistic about the practical problems of reconvening groups for a second and a third meeting. Since the focus groups were organised in association with a related event, participants were drawn from delegates at those events. This kept costs low, as well as ensuring that participants could be expected to share similar interest and therefore motivation. On the other hand, there was no guarantee that the same delegates would attend the other events, which would compromise any continuity or the development of issues arising in an earlier group. The main disadvantages with the decision not to reconvene were that it would not be possible (a) to explore any longer term group dynamics (participants aligning themselves with other participants or stakeholders, but then changing their views over time), (b) to monitor any changes in perspective or views, and (c) capitalise on any nascent group dynamic (such that the discussion could begin directly without participants having to acclimatise). In the end, because of time constraints and the advantage of seeking motivated and experienced participants from the parallel events, we decided not to reconvene with the same participants and on the same topic. Nonetheless, we did explore the same topic on several occasions but with different participants for one specific case (one of the Athens focus groups was re-run in Aalborg, including stakeholders who had not previously been represented).
2.7.
Number of Groups
Focus groups are labour intensive in recruitment, transcription and analysis. Therefore, where possible, numbers should be kept down to a bare minimum. We decided therefore that experience with initial focus groups at events such as FIA and the SESERV Athens workshop would determine the optimum number of groups to run, starting with three on economic (network-centric) and two on societal themes.
Public
Based on the feedback received after the Athens Workshop [3], where half of the participants indicated that the perspectives of content owners were rather missing from the workshop, we invited delegates at the FIA event in Aalborg to a fourth focus group to study the impact of QoSaware interconnection on delivering gaming services.
2.8.
Recruitment
Systematic random sampling is not very important because the aim of a focus group is not to make generalizations to a population in the same way that large-scale quantitative methods may have as their goal. In addition, it was anticipated that participants would be representative of different FI ecosystem stakeholders, attending the focus groups voluntarily and as an interesting complement to the discussions they would have witnessed at the parallel event. The SESERV project targeted suitably experienced participants at those events. Guaranteeing participation was a challenge, depending on the event. At the FIA Aalborg event, for instance, the event programme meant that some of those who wanted to attend would have had to alter travel or other arrangements. In addition, many potential participants had had to develop material for the demonstration and poster sessions and had not therefore been able to sign up for the focus groups when advertised. In future, recruitment needs to be considered carefully, perhaps involving individual targeting rather than generalised advertising.
2.9.
Rle of Facilitator
The level of interaction between participants is largely dependent on the rle taken by the group facilitator. There are low and high levels of moderation. Low-level moderation means that the facilitators rle in the discussion is kept to a minimum. Data produced in this way can be said to be free of researcher influence and this is certainly a valid reason for choosing to adopt this level of moderation. There are a few problems with this low level of moderation. The first is that the discussion might wander away from the set topic. Another problem might be that some individuals may dominate the proceedings [10]. High-level moderation means that the facilitator assumes a high degree of control over the direction and nature of the discussion. Questions are asked in a specific order and there is little opportunity for participants to deviate from the topic or to raise issues of concern to them. Highlevel moderation is likely to impede rather than facilitate group discussion and interaction. In practice the majority of focus group facilitators opt for a level of moderation somewhere in between these two extremes (ibid). We had originally intended that the facilitators of the SESERV focus groups use medium level moderation: they were encouraged to perform a guiding rle in the discussion, ready to interject, ask questions and probe for further information when necessary. In contrast to low-level moderation, this approach has the advantage that, as a facilitator, you can maintain a greater degree of control over the direction of the discussion, hence ensuring that the data are relevant to your research question (ibid). For the SESERV focus groups, the facilitators found in practice that they needed to adapt, sometimes dynamically, to the way in which any particular group was running. In general, a low-level of moderation was the default position. Ann Cronin (op cit) gives a lot of practical advice for facilitators in her article. We used her suggestions to compose a guideline for the facilitators of the focus groups. Introduce yourself, welcome the participants Hand out the self-completion questionnaires Collect the questionnaires Make a statement about what you intend to do with the data collected Assure confidentiality Let the participants know that you are not seeking right or wrong answers. You are interested in hearing what they have to say
Public
Opening circle where participants give their name (& other relevant info) Make a note of the names and where they are sitting Ask one or two opening questions (for instance: ask participants about their understanding and definition of user-centricity, multi-disciplinary approaches, or specific network issues) Use focusing exercise (as appropriate) Ask 2 to 5 key questions Repeat original questions if necessary (when participants start to drift) Draw to a close with an ending question Closing circle Summarise key points of discussion and ask participants if they agree with this summary
For the SESERV focus groups, facilitators were used from the consortium with appropriate experience and expertise in the areas covered. As such, briefing material could be kept to a minimum.
2.10.
Choice of Venue
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). Furthermore, focus group sessions should be, wherever possible, free from interruptions or surveillance with no non-participating delegates wandering in. Too much background noise would compromise the audio recording, and all the participants would need to be able to see and hear each other. The venue would have to be one where people felt comfortable enough to sit and talk for a couple of hours. Whatever venue was ultimately chosen, the venue itself is known to have some impact on the data collected as touched on above. The formality of the group discussions may vary with the formality of the setting. There is no such thing as a neutral venue for a focus group [11]. In Athens, rooms being used for the workshop were also used for the three focus groups, and in Aalborg, rooms were hired at the venue; as such they were familiar to the participants, if a little formal. The same was true for the other societal focus groups: rooms at the venue for the background event were reused for the focus groups. The following checklist of equipment is suggested to be used for running a focus group [10]: Digital recorder with cord/leads Remote microphone Extra batteries Video recording equipment Pads/pens or whiteboard for the moderator Copies of the focus group schedule A list of participants Pens/paper for participants (if necessary) Handouts (if appropriate)
For the SESERV focus groups, as already stated, the intention was to run focus groups at related events. This would represent an extension of the event itself, which may have benefits as well as drawbacks. On the one hand, it would present a semi-formal environment where related discussion
Public
and topics had been presented and debated (though not necessarily by the focus group participants themselves). On the other, whatever atmosphere had pervaded the parallel event might have spilled over into the focus group discussion.
2.11.
Audio and Video Recording
For the analysis of focus group data we aimed to collect an audio and a preferably video recording of every single group. Audio recording equipment that is suitable for recording one-to-one interviews may not always produce a recording of sufficient quality when used in group settings and so was not used. The microphone component is crucial, of course. Having audio recordings of sufficient quality is important for transcribing the sessions.
2.12.
Length and Payment Length
2.12.1.
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. We decided that the timeslot of the focus groups had to be less than two hours. Within that period sufficient time was to be found for the completion of a pre- and post-group questionnaire as well as any post-group debriefing, if used. The group itself would not run longer than an hour and half, therefore. Even if the group was going very well and the group members appeared very enthusiastic, the facilitator was asked to wind things up after 90 minutes (Bloor et al [11]). Any planned short pre-group questionnaire and focusing exercises were designed to fit into the overall timeslot. At all costs, the facilitator has to avoid the premature departure of some group members, altering the composition and dynamics of the group; such premature departures would be increasingly likely as time goes by (Bloor et al [11]).
2.12.2.
Payment
The convention of paying a fee to focus group members probably stems from focus groups commercial history in market research, where the fee offered by market researchers is a considerable aid to recruitment, especially among the young and disadvantaged. Against the convention of offering a fee to attendees in academic focus group research, it may be objected that ethnographies and depth interviews may also cut deeply into the research subjects free time, but in these cases no fee is sought or offered (Bloor et al [11]). However, focus group members may also incur additional expenses not incurred by participation in studies using other methods transport costs to the venue, possible loss of earnings, the possible need to make child care arrangements, etc. So the attendance fee for group members in academic social research is generally termed an attendance allowance for out-of-pocket expenses (currently around 15 to 25 per person). When no fee is paid it may be possible to offer thanks in kind (light refreshments). Within SESERV, we considered whether or not to pay the participants an attendance allowance or equivalent incentive. However, since the intention was to run focus groups at suitable, related events, participants would already be on site and available. We decided therefore to confine payment to a small thank you by way of refreshments provided during the groups themselves8.
For example, the WP3 FG in Oxford was organised early in the morning and participants were offered breakfast,
Public
2.13.
Tools and Techniques Pre- and Post-Group Self-Completion Questionnaires
2.13.1.
Some basic socio-demographic information such as age and marital status are typically gathered for analysis purposes and this may be most appropriately collected immediately before the group starts. For the SESERV focus groups, this is of little relevance. More important is the perceived and actual background of the participants: do they represent stakeholders of a given type from the FI ecosystem, for instance? How has this affected their contributions and their interactions with others? The detailed transcripts used such information as stakeholder type to identify and thereby anonymise the participants contributions. An a priori questionnaire was to be developed to establish how participants felt about their own rle in respect of the FI ecosystem, and where there main interests lay. Further an a posteriori questionnaire was to be used to gauge how and if their views had changed during the discussion. In the event, this was not done: recruitment (see Section 2.8 above) had proved challenging, and with the exception of the SESERV Athens Workshop focus groups [3], those participating had welldefined ideas from their own project participation and experience as well as the fact that they were taking time out of a business event schedule. In consequence, questionnaires before or after the FGs were not used.
2.13.2.
Presentation Material
Depending on the participants familiarity to the topic(s), presentation material to seed discussion may be necessary. The requirement for WP2 and WP3 are rather different here. For the economic, network-centric focus groups, seeding discussion with solutions proposed by existing FI technology providers would help initiate and bound proceedings. By contrast, since participants for the societally focused groups may not have much generalised experience of Digital Agenda obstacles and the broader challenges facing the FI, it would be helpful to give a short introduction about the main issues. For the facilitators an additional text above and beyond the presentation material was to be provided. The intention of this material was to aid the facilitator in moderating the discussion where they may not be expert in all areas of relevance. For WP2, this was done in part via the presentation given by the individual projects to initiate discussion at each FG, where the facilitator was already engaged with the project. For WP3, it transpired that participants were already very much engaged in related FI discussions, not least from observations at the parallel events themselves; briefing would not therefore be of any particular benefit and may be counterproductive. It was apparent for all FGs in both WPs that this did not appear to hinder participation.
2.14.
Discussion List of Issues
2.14.1.
For the facilitators it will be important to have a list of issues at hand that need to be discussed, so that the different focus groups will all deal with the same topics. Otherwise comparison during the analysis phase will become almost impossible. It is important not to have too many issues that need to be discussed. The time is limited and we want all the participants to be able to say what is of importance to them as individuals or within their own domain.
Public
As mentioned above, WP2 seeded each focus group with a project presentation. In Athens, a number of different projects kicked off three different discussions9; however, in Aalborg, the focus group revisited the subject matter of one of the Athens groups, beginning with the same project presentation. The WP3 focus groups made use of a short list of questions to help steer the discussion.
2.14.2.
Focusing Exercises
It is possible to distinguish focus groups from group interviews. In group interviews, the group is asked a sequence of pre-determined questions, just as if the interviewer were speaking to a single interviewee: the group format is simply a matter of convenience. By contrast, for focus groups predetermined questions may also be asked, but the objective is not primarily to elicit the groups response but rather to stimulate discussion and thereby understand the meanings and norms that underlie those group answers. In group interviews the interviewer seeks answers, in focus groups the facilitator also seeks group interaction (Bloor et al [11]). The facilitators questions are thus a focusing exercise: an attempt to concentrate the groups attention and interaction on a particular topic. The exercise need not, and frequently does not, take the form of a question, instead the group may be required to perform a specific task. One commonly used type of focusing exercise is a ranking exercise: the group is offered a list of statements and asked to agree among themselves a ranking of the statements in order of importance. Different groups will commonly produce differences in rankings. But more importantly, the discussion about the rankings itself serves to illustrate the deep differences (along with some important similarities) in the tacit understandings of each different group (Bloor et al [11]). A number of ranking exercises could have been developed for the SESERV focus groups: such focusing exercises may be useful because they may give impetus to group interaction. Also the props of the exercise (the printed cards lying on the table) may themselves provide a convenient reminder of the groups task and thus a silent guard against straying into irrelevancies. The task itself can also function as an ice-breaker, to help participants become comfortable if they are discussing in a group setting for the first time. For the SESERV focus groups and as discussed in the sections above, there were a number of practical considerations to be taken into account here: 1. Group session experience: FG participants can be thought of as knowing each other either directly or via knowledge of the field of study and/or past work. There should therefore be little reason to impose an additional activity as an ice-breaker; 2. Seeding exercises: since participants had chosen to attend the parallel or associated event, it was felt that any seeding exercise to initiate discussion could be kept to a minimum; 3. Common background a. FI Ecosystem: since they are engaged in or have knowledge of Challenge 1 projects, all of the WP2 FG participants could be expected to have some familiarity with the domain, as well as be motivated to examine it further; b. Socio-economic awareness: with direct knowledge through project or related work in the area, WP3 FG participants could be expected to know of the socio-economic concerns surrounding the Future Internet not least through the TAFI report11 and the final reports of the Study on the Social Impact of ICT10.

The first two focus groups at the SESERV Athens workshop each began with a presentation from each of two projects; the third group began with a single project. Refer to deliverable D1.4: Second Year report on Scientific Workshops for the specific projects and topics covered. 10 http://ec.europa.eu/information_society/eeurope/i2010/docs/eda/social_impact_of_ict.pdf
9
Public
The different WPs adopted slightly different approaches in this respect. For WP2, FG attendance was largely drawn from those involved directly or otherwise with Challenge 1 projects and with a view to finding representation from all relevant FI Ecosystem stakeholders. Each FG was initiated with one or two project-related technical presentations, which was regarded as sufficient focusing exercise. For WP3, FGs were based around related events; participants were drawn from event delegates and therefore by definition would be motivated in the domain as well as often having some experience of working with or reviewing the work of other participants. In consequence, focusing exercises were kept to a minimum: in Aalborg, a figure from the TAFI report11 was used to initiate and focus discussion in emphasising who may be currently driving the development of FI technology and who should actually be driving.
2.15.
Conclusions on Focus Group Methodology from SESERV
In view of the previous sections, a number of recommendations and conclusions may be made. These are outlined in this section. FLEXIBILITY The overall Focus Group Methodology as defined in the literature should be tailored to the specific needs of any individual focus group or area.
In Advance Blanket and non-specific advertisement of the focus groups may not have attracted participation, not least because delegates at the host event will tend to be caught up in their own preparations. Targeted Identifying stakeholder rles in advance and making sure they are represented may help establish to whom invitations should be directed. RECRUITMENT Payment Because of competing schedules (such as the event programme where the FGs are being held), there is some motivation to provide actual payment to ensure enough and appropriate participation. Stakeholders Explicit (WP2) or implicit stakeholder representation may not be guaranteed. This should be addressed during recruitment, possibly by targeting participation. Venue Exploiting related events and using the same venue has many advantages, not least in providing a known setting for a more relaxed discussion. However, this does mean that the scheduling of the FGs may have to occur before or after the main event, which may affect participation. Participants Using parallel or related events helps with recruitment and logistics: participants are a priori motivated and interested in the general theme of the event and so will be knowledgeable about the area of discussion, and can be expected to be able to make some useful contribution not least from the perspective of why they came to the event, their expectations and what they have got from the event. Dominant High-level moderation may be necessary so no individuals may voice dominate the proceedings This was not found to be a particular issue for the SESERV Focus Groups; perhaps this was on account of

11
EXPLOIT LOCAL CONTEXT
http://www.internetfutures.eu/wp-content/uploads/2010/11/TAFI-Final-Report.pdf
Public
participants being known to each other and familiar with the modus operandi of other participants. Focus/seeding There may be less of need for focusing exercises not least because: activities participants will typically have some knowledge and/or experience of each other; participants can be expected to know about the general domain; participants will be motivated to discuss their experiences and opinions.
The following section introduces the tussle analysis methodology and presents how it can be applied by using a case-study from the ETICS research project.
3. Introducing and Applying the Tussle Analysis Methodology

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 functionality 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 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 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
Public
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 sources simultaneously) 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 home routers 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 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. The exact order depends on the specific context; e.g., due to outsourcing, it might 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 over which such relatively minor adaptations (that dont 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. For example it may take some time for the stakeholders to experiment in using a new technology to meet their objectives. 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 whom 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. 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 new tussle cycle, where some other (possibly, 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 and/or common policies by a significant fraction of a stakeholder group. Often 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.
3.1.
Tussle evolution
According to our previous discussion, a 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. It was 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 one of the possible Nash equilibria 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. The study of such evolutions 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 new tussle based on:
Public
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 taking coordinated technology decisions, or new socio-techno-economic decisions following the basic socio-economic technology cycle described before, e.g., introduce a radically different technology, use a technology option in an unforeseen way.
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. This is called a spillover effect. It should be noted that stable tussle outcomes can also create spillovers to other functionalities, in cases where some users of the established functionality find some new uses for it, not anticipated before, which interfere with other functions of the ecosystem. These are cases of negative externalities (i.e. adverse effects) between different functionality spaces. Positive externalities may also appear, for example more resources become available to a functionality due to the introduction of a more efficient technology to another related functionality. 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 technology implementing a particular functionality do not hold anymore and allows a tussle of different functionality to reach an unfair outcome. These effects can also happen when technology that is used during a tussle, can be repurposed and used in a way that imbalances different tussle of another functionality (which may involve different stakeholders). a a a a
Figure 2 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).
Figure 2: Tussle evolution due to instability and externalities
Public
SESERV believes that analysing the anticipated tussles can shorten unstable periods and help the adoption of a long-term successful technology and configuration. Tussle Analysis defines a systematic approach for understanding the impact of introducing new Internet technologies, by trying to answer the following questions: Is a new technology needed today and why? o o 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 outcome in terms of performance and stability? How would the interests of existing and new stakeholders be affected? How would the options of existing and new stakeholders be affected?
What would be the effect of a new technology to the ecosystem in the future?
Can this technology help reaching a fairer outcome regarding this functionality, or increase efficiency in the case of an already stable outcome?
3.2.
The tussle analysis methodology
The SESERV project has defined a systematic approach for analysing and assessing the importance of socio-economic tussles in the Internet. This methodology initially outlined in [2] can be useful when designing new Internet technologies for understanding the expected impact to the stability and efficiency of that particular functionality space and possible spillovers to other spaces. Selecting the features of a technology in a more holistic way, by taking into account the socioeconomic requirements would lead to more attractive outcomes and increase the chances of that technology to be adopted in the long-term.
Figure 3: High-level view of tussle analysis methodology 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. 3. For each tussle:
Public
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 3 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 landscape for that particular functionality. In order to make those 'functionalities' more concrete we decided to use an extensive taxonomy of Internet functionalities, which covers both aspects of how services are being hosted (cloud-related functionalities) and their actual delivery (network-related functionalities). To avoid reinventing the wheel, we adopted the network functionalities taxonomy as described in [12]. The reason for selecting this particular taxonomy is that each functionality was found to be well separated from other complementary ones. While each of these functionalities can be decomposed further into sub-functionalities, they can also be seen as components for composing more complex network services.
Figure 4: A Taxonomy for Internet Functionalities More specifically:
The Transmission functionality 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 functionality 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) functionality 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, etc.). The Mobility functionality would include protocols for handover and location management.
Public
The Security functionality would cover protocols for authentication, authorization, accounting, monitoring, encryption, redundancy, data integrity, and key distribution. The Naming/Addressing functionality would include naming schemes and name resolution techniques.
Unfortunately, we couldnt find a suitable taxonomy for cloud functionalities; thus we proposed a new one. More specifically:

Virtualization, which includes image creation, image deactivation, image portability (to different machines), etc. 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, etc. Security that includes monitoring, accounting, SLA management, admission control (for security reasons), etc.
It is important to note that each functionality 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 functionality, but MPLS signalling for setup of QoSaware paths perfectly fit into that functionality. The first step is centred on identifying and studying 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. Figure 5 presents a synthesis and classification of Future Internet stakeholder roles into 7 categories by SESERV [5]. 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 functionality, or take a single role that can differ across instances of that functionality. 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 functionality, 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 functionality. These technologies, or technology sets, usually follow a different logic or may not even be designed for implementing that 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 the technologies that these rational entities would select in order to meet their goals. Thus, this step is about instantiating Figure 1 in the specific context of this functionality. To address this step in 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 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.
Public
Control where two or more actors have different views on how a set of complementary resources should be combined.
Figure 5: 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 a diagram like the one in Figure 3. In the ideal scenario of a tussle outcome is an equilibrium point, where: a) all stakeholders of that functionality derive a fair12 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 on to the remaining tussles identified in Step 2. In the case where condition (a) is not met, a new iteration of the methodology must be performed by making assumptions on the most probable

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.
12
Public
policies adopted by unhappy 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 cases where no such improvement takes place, the technology designer should examine whether a change in the implementation details would lead to a better outcome. The tussle analysis method introduced in this section is of interest to European research projects since one of the key findings made from the SESERV Oxford workshop shows that many of the projects interviewed focused solely on direct controlling parties, those providing the funding, regulators and the consortium partners themselves. This means that some relevant considerations are missed, not least in considering the specific impact of the technology on those who will use or be affected by it13. The tussle analysis method constitutes a suited tool for research projects to do exactly 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 with Dewandres keynote speech in which she stated that all stakeholders should engage [14]. If both conditions hold then the analysis of that particular tussle has completed and we can move on to the rest tussles identified in Step 2. If any of the conditions above does not hold then we need to examine the specific tussle in some detail to establish what might be done to restore equilibrium between the stakeholders involved. Technologies proposed by research projects can be designed towards this direction. In the case where condition (a) is not met, we must perform a new iteration of the methodology 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. Figure 6 gives a more detailed view of the tussle analysis methodology and the purpose of each step. Each purpose is depicted as a diamond while the colour determines whether that task refers to 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 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 Functionality 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.

13
http://www.seserv.org/panel/videos-interviews
Public
Figure 6: A detailed view of tussle analysis methodology
3.3. Case study: Customer SLA Monitoring and Incentives for Backup ASQ Provisioning
The ETICS project proposes a set of technologies and the associated economic mechanisms so that participating providers can jointly offer premium connectivity services to their customers. These services to ETICS customers are provided by stitching connectivity agreements (called Assured Service Quality (ASQ) agreements or goods) from several ETICS providers. The ETICS products 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; this path may be different than the path returned from Border Gateway Protocol (BGP) in order to meet the QoS constraints demanded by the customer.
Figure 7: A Scenario of SLA Violation Identification Using the Hierarchical Monitoring Approach
Public
In Figure 7, ISP-3 has created an atomic ASQ good with certain properties between its routers F, 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 to ISP-1. Thus ISP-1 can reach through ISP-2 and ISP-3 the Content Provider and serve the customers request for premium connectivity. Two SLAs will be created for this end-to-end service at the ETICS marketplace; one among ISP-1 and ISP-2 for the path between C & H and another one between ISP-2 and ISP-3 for a path between F & H. Both ISP-2 and ISP-3 will have to manage their network so that all SLAs are honoured, for instance select one out of many intra-domain paths available to route that particular traffic. Furthermore, ISPs usually interconnect at multiple locations for more routing options and increased reliability. Suppose now that there is a failure of some kind on the network of ISP-2. Typically, failover will be catered for and the service can continue across any backup path. However, before the recovery completes, the end-user may notice degradation in the quality of the service provided by their ISP and the QoE SLA could have already been violated. SLA monitoring is the process of collecting the necessary information when services are being delivered, in order to establish conformance to contract terms. This functionality is considered to be important even when trusted operators (as in the case interested in ETICS) must collaborate in order to provide QoS-assured services end-to-end. Discussions during the third focus group revealed that press plays significant role in bringing transparency into the Internet connectivity market, at least for the ISPs who are interested for their reputation. This importance can be attributed to the fact that such premium transport services are secured by SLA terms and can trigger payments to the customer in case some of the ISPs in the ASQ path fail to meet its requirements. The existence of monitoring technology when network operators offer services that are not under their complete control (since more than one ISP 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 to keep capital and operating expenses low. In this case study we look at another interesting implication of monitoring related to the reservation of backup capacity, but it can be easily shown that a carefully designed mechanism can deal with cases where some ISPs underperform systematically. Although not directly mentioned in the SLAs, ISPs are expected to keep backup 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 which might cause a QoS degradation and hence an SLA violation. This can happen either because the new path in his own network violates what is promised by the SLA, or because he directed the traffic to some different ingress point of the next ISP in the path and this ISP had not been geared to 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 no adequate 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 that interfaces to the customer of the ASQ agreement), or can be divided equally among the ISPs. One can easily see that at the equilibrium, ISPs will pick a strategy to provide minimal backup. There is obvious 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 identified for 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 Internet stakeholders make that can lead to unfair allocation of SLA violation penalties? The aim is to
Public
identify 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 be identifiable 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 provides the control of network devices to be handled programmatically. We will apply the tussle analysis methodology to the distributed hierarchical scenario, as the more likely to be deployed. In this particular scenario, 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 to the 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 dedicated databases, 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 in order to check the validity of each SLA violation ticket. ISPs or trusted third parties can act as Brokers operating collectors. The main set of stakeholder (roles) includes ETICS Information Providers (Brokers), ETICS Communication Service Providers and more specifically Edge and Transit ISPs. Other involved roles are Content Providers, consumers of ICT services and Regulators. Again, for brevity, we will concentrate on the first set of actors and stakeholder roles. Figure 8 shows a possible evolution of the tussle described above between a Transit ISP (ISP-2 in our example) and Source, Destination ISPs (such as ISP-1, ISP-3 respectively). Investigating the Transmission functionality, as long as Best Effort is the only traffic class available on the Internet, no SLA monitoring is needed and thus we assume 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 will be used in case of a sudden failure. All ISPs however have the incentive not to announce sensitive information 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. This means 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. Suppose that the SLA between the transit ISP-2 and the destination ISP-3 allows occasionally the former 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 ISP2 goes down due to some hardware failure, which affected its ability to continue using the same ASQ. 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 constraints inside its network, whereas the ISP-3 fails to meet the terms of the SLA with ISP-2, because the backup ASQ is not properly dimensioned. In absence of any SLA monitoring mechanism (lower part of Figure 8) ISP-1 cannot infer whether its his responsibility or another ISP along the path (and even if he does he would have difficulties 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 could lead to a market failure due to misaligned incentives; an increasing number of ISPs will have to lower their cost, having a negative effect on customers QoE and thus on demand for premium services. At the same time, Users and Content Providers have no means to backup their claims when they experience degraded quality. This issue has been raised during the Athens Workshop, where the User representative was unsure whether he would actually get the premium experience that he had paid for. Even though, in fear of losing the customer a Source ISP has the incentive to admit
Public
his fault, problems are expected when the disruption is rooted at a Transit or Destination ISP. So, in absence of a monitoring mechanism the outcome of that particular tussle is in favour of the ISPs and especially the Transit ones.
Figure 8: Candidate Tussle Evolution for ETICS Network Service Delivery As was discussed during the 3rd Focus Group in Athens, currently, technically-savvy users bring transparency into the market by periodically announcing their findings to websites accessible by potential customers. Furthermore, the fact that the metrics and applications being measured are constantly changing, was indicated to give incentives to reputable ISPs to keep their effort high. This means that experts and social media can bring the system into a more balanced state. In an ideal scenario such a reputation system would lead the system to a stable state as well, but this is not to be expected soon since the majority of ISP customers dont base their decision on performance-related aspects [13]. Let us examine the case where a trusted third party (a broker) implements the hierarchical SLA monitoring 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 the compensation to the ISPs, could lead to a stable tussle outcome. However, depending on the implementation of the SLA monitoring mechanism identification may not always be feasible. We identify two cases for the SLA monitoring technology for illustrative purposes; a simple one and an advanced one. In the first case where sample packets were known in advance, Transit and Destination ISPs could forward probing packets preferentially. Thus the responsible ISPs may not always be identified. This means that the total payments made for customer SLA violation is analogous to the number of end-customers that ISPs have. Assuming that a Transit ISP has fewer customers than an 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 during service provisioning and they have to save a timestamp for those packets at the egress router.
Public
Following a secret algorithm for statistically selecting those packets, a Broker could make harder the expedite forwarding of sample packets only14, giving the right incentives for correct dimensioning of backup paths and lead to a stable outcome for the Transmission functionality. Otherwise, the ISP being responsible for SLA violation would be highly likely to be identified and thus be asked to compensate the customer. Such a mechanism could be configured so that a timestamp is stored at the entry point of the Source ISPs network as well as the egress point of the Destination ISP, allowing the broker to examine whether a customers complaint is valid, or not. However, it should be evaluated whether this mechanism would lead to a stable state without posing negative externalities to other functionalities.
4. SESERV Recommendations
SESERV collaborated with a broad set of research projects and members of the FISE community, either directly or in the context of SESERV events, resulting in the identification of a wide variety of socio-economic issues relevant to Future Internet. A series of recommendations has been offered which is based on the consultations with the FISE community over the last two years. These recommendations are not meant to be exhaustive since SESERV was not a research project, but a coordination and support action. Thus, these recommendations are ones which we make in support of the community of the Future Internet, based on what they have told us are priorities.
4.1.
Economic SESERV Recommendations
This section provides a set of 6 SESERV economic recommendations to research projects, providers and policy makers for successfully redesigning and configuring Future Internet technologies, as have been identified in [5]. These are: 1. Technology makers should understand major stakeholders' interests. 2. Technology makers should be neutral. 3. Technology makers should explore consequences and dependencies on complementary technologies. 4. Technology makers and Providers should align conflicting interests through incentive mechanisms. 5. Technology makers should increase transparency. 6. Policy makers should encourage knowledge exchange and joint commitments.
Recommendation 1: Technology makers should understand major stakeholders' interests

One of the consequences of Internet commercialisation is the emergence of conflicting interests amongst its stakeholders. This phenomenon, which is not restricted to Internet, has been recognized by researchers long ago, who argue that identifying and studying the properties of the most important stakeholders is necessary. Figure 5 provides a classification of Future Internet stakeholders that can be used as a starting point during the identification phase. When identifying the important stakeholders it usually helps to think of particular instances, but in order to study their interests more accurately it is important to think in terms of stakeholder roles. The idea is that the

Other issues that should be considered are the integrity of data stored for the sample packets at proxies and synchronization of routers clocks. An ISP, for example, could report biased data by subtracting few milliseconds from actual data.
14
Public
same entity can perform several tasks (or make several decisions) during a particular session and these actions may be interrelated. For example a mobile operator bundling connectivity and communication services in a pay-as-you-go would be interested in blocking network access to third-party VoIP services. On the other hand, a provider of landline communications-only would accept calls from every operator. The SESERV coordination action, based on the fact that the Internet is an environment of constant and fast changes, argued for the need to study stakeholders interests along the time dimension. This goal can be achieved by applying the SESERV tussle analysis methodology, which examines how self-interested stakeholders would react when interacting with other rational stakeholders15. An example of this is the OPTIMIS project, where tussle methodology showed that the long term effects of the project technology would slowly alter the equilibrium, favouring one party over another. We should note that the tussle analysis can be applied in association with other complementary approaches, such as the MACTOR methodology [18], [19] for identifying feasible future value networks.16 Report [5] provides a detailed analysis of the way the interests of several stakeholders are expected to evolve over time for case studies of 8 research projects. The tussle analysis method introduced in this section is of interest to European research projects since one of the key findings made from the SESERV Oxford workshop (cf. [4] for details) shows that many of the projects interviewed focused solely on direct controlling parties, those providing the funding, regulators and the consortium partners themselves. This means that some relevant considerations are 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 do exactly that, namely to assess socio-economic dimensions in a structured manner considering all stakeholders of relevance to the technology a project develops or studies. Selecting the features of a technology in a more holistic way, by taking into account the interests of the major stakeholders would lead to more attractive outcomes and increase the chances of that technology to be adopted in the long-term. In order to get a representative idea of stakeholders interests it is important to interact with actual representatives of the stakeholders themselves and ensure that they are motivated to express their genuine thoughts. SESERV has been interacting with Internet stakeholders during its lifetime in several events and organised a number of focus groups, engaging participants into a dialogue.
Recommendation 2: Technology makers should allow all actors to express their choices
Clark et al. [1] suggested that Internet technologies should follow the Design for Tussle goal and be designed for allowing variation in outcome. The rationale was that Internet is a rather unpredictable system and it is very difficult to assess whether a particular outcome will remain desirable in the future. A technology, such as an Internet communication protocol or an Internetbased application, compatible to the Design for choice principle should lead to a stable outcome by allowing all involved stakeholders to express their interests and affect the outcome. The Design for choice principle provides guidance in designing protocols that allow for variation in outcome. This is related to Kelly Johnsons KISS principle (Keep It Simple, Stupid), which suggests that Internet technologies should not make any technical assumptions or be optimized for a particular service or context. The reason is that these assumptions may not be valid in the near future, posing obstacles to the smooth evolution of the Internet. Useful properties are:

15 Rational stakeholders, in economics literature, refer to those entities who always act in ways that maximize their net benefit. On the other hand irrational stakeholders have a less predictable behaviour, which can be attributed to several factors (e.g., altruism, imperfect assessment of the present situation). It is obvious that the latter stakeholder type is a more realistic assumption when human entities are involved. 16 The details of combining tussle analysis and MACTOR methodologies with UBM (Unified Business Modeling) will be explored between members of the SESERV and UNIVERSELF projects, after the end of SESERV projects lifetime.
Public
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.
Note that the Design for choice principle is directly related to the FIArchs "Exchange of Information between End-Points" seed for new design principles [20]. The main difference is that the latter focuses on dealing with Information asymmetry issues, and thus does not cover the Visibility of choices made property.
Recommendation 3: Technology makers should explore consequences and dependencies on complementary technologies
The second principle implementing the Design for Tussle goal suggests avoiding spillovers to other functionalities and helps in identifying whether tussle spillovers can appear. A protocol designer can check the following two conditions: Stakeholder separation, or whether the choices of one stakeholder group have negative side effects on stakeholders of another functionality. Functional separation, or whether the absence of a particular feature in a set of technologies promotes users to repurpose a technology from another functionality. In this case, the technology maker should consider implementing the missing functionality in a complementary technology.
Recommendation 4: Technology makers and Providers should align conflicting interests through incentive mechanisms
There are several cases where stakeholders have conflicting interests. In case of a scarce Internet resource, for example IP addresses or bandwidth on a common network link, a number of stakeholders may compete for receiving enough share of the resource. Similarly, in a value chain where a principal delegates control to an agent for performing a task, these entities may have different preferences over the possible outcomes. These situations are not limited to the Internet and traditionally have been dealt with as economic mechanisms. Such market mechanisms provide the opportunity to (i) align resource consumption with utility in case of contention for resources and (ii) align costs and benefits in case of distributed control. Absence of suitable economic mechanisms can cause market failures; for example, if only flat pricing schemes were available, contention for resources would lead to the tragedy of the commons. The idea here is for technology makers to provide all involved stakeholders with access to the necessary information, as well as the necessary functionality so that each participant can afterwards take an informed course of action and allow tussles to be resolved in a more predictable way. This would allow Connectivity/Information/Infrastructure providers to announce multiple service plans and available configurations for meeting customer demand and covering their costs. For example, providing customers with the ability to control advanced service features (such as the exact network path to be used) increases providers cost and should be charged higher. This gives greater flexibility to providers for fine-tuning their offerings and customers in selecting the service plan (covering service attributes and contract details such as pricing scheme) that suits his/her usage profile.
Public
There are several types of economic mechanisms that a technology maker could choose for aligning the conflicting interests that have been identified. Such incentive structures include charging schemes, rewarding systems and reciprocal mechanisms. The first mechanism suggests that when a choice has negative impact on some other party, the party making the choice should contribute to the cost. Similarly, the second mechanism suggests that when a choice has a positive impact on other parties, the party making the choice should also receive part of the benefits. On the other hand, reciprocal mechanisms are suitable for relationships created for the mutual benefit between peers, e.g., transit cost avoidance in the case of peering interconnection agreements. The purpose of each charging mechanism should be to signal the current price at which a supplier is willing to provide a potentially scarce resource or a costly service feature, so that consumers can select product offerings and adjust their consumption according to the value the usage brings them and the cost it incurs. An unconditioned flat rate is one extreme case; being very popular to end users but giving inappropriate incentives since they are charged independently of their consumption. Congestion charging is another family of mechanisms that makes someone responsible for their actions impact (negative externality) on the system. The main problem with usage-based pricing schemes for charging users is that they increase providers cost and customers uncertainty, and thus are not always easy to be adopted. An ISP, for example, may be reluctant to apply such a scheme in fear that revenues from the number of users willing to have a less congested network (at the clearing price) will not cover the extra costs. Studies have shown that end users prefer simpler prices. For example, Odlyzko noticed in [21] that there are repeating patterns in the usage histories of several communication technologies, including telephone networks and the Internet, showing that sophisticated pricing schemes are difficult to be widely deployed.17 On the other hand, the application level has readily embraced payment for usage, through the cloud model. It should be remarked that this was partly due to much lower barriers for new entrants (c.f. Amazons dramatic entry into cloud provision) and due to a simple utility model for payment according to units of resource used. Similarly, advanced charging schemes have been also proposed for the ISPs interconnection market18. For example, Falk von Bornstaedt in the Athens workshop described the Sending Party Network Pays principle as an enabler for QoS-aware Internet19. The reason is that provides the ISPs with the right incentives when they receive a packet marked with high-priority. Thus, 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. Reward systems provide incentives for either exceptional behaviour or encouraging adoption. Reward can be in real money, virtual currencies or in-kind by the provider. The problem with financial compensation is that it increases the cost to the provider and thus cannot be applied systematically. For example, in the case of ULOOP project it was found that covering part of the cost of relaying another users packet would help in the system being adopted [5]. But the economics literature suggests that no incentive compatible mechanism can be produced without relying on subsidies from external sources20. Similarly, several implementation issues hinder offering virtual currencies. On the other hand, mechanisms that rely on providing rewards in kind (for example preferential treatment) are much easier to implement.

However, using special software and/or hybrid charging schemes could mitigate users reluctance. For example, flat pricing could be employed for all users with an extra charge for the congestion that they cause. But users could limit the congestion charges by configuring their software how to react in case of congestion. This method of pricing might reduce traffic and free some scarce resources at peak hours. 18 For an extensive overview of existing and proposed interconnection models the interested reader is redirected to [23]. 19 http://www.seserv.org/athens-ws-1/webcasts#bornstaedt 20 Myerson and Satterthwaite showed that it is impossible to simultaneously achieve perfect efficiency (that is maximizing total agent value), budget balanced (subsidies are necessary), and individually rationality (no agent would pay more than its valuation for the goods it receives) from an incentive compatible mechanism (in which case an agents dominant strategy is to simply report its private information truthfully) [24].
17
Public
Reputation systems bring memory to the system by keeping the history of participants interactions together so that the trustworthiness of the entities can be estimated. The idea is that entities in collaborative environments will have the incentive to cooperate if they know that it will affect their future ability to participate in the system. Even though reputation systems are not trouble-free, such methods can deter the majority of the misbehaving users. An interesting example of how Internet stakeholders can react in absence of a technology that leads to a fair tussle outcome is the CIDR report21, which provides on a weekly basis information about the ISPs who act selfishly and do not follow good practices22. Making this information available to mailing lists (or even workshops) where ISPs discuss operational issues and concerns (such as the NANOG23 mailing list) acts as an incentive mechanism. In general, such incentive mechanisms can make the set of technologies, which follow the design for tussle paradigm, more attractive to their intended users (such as end users, ISPs, etc.) and boost their adoption. We should note that the rest technologies will probably still be available but all users today can have access to the necessary information for making decisions that are aligned with their interests (thus are not expected to act irrationally). FIArchs Sustain the Investment seed for new design principles [20]. The idea is that incentive mechanisms will be necessary that lead to favourable outcomes for all stakeholders.
Recommendation 5: Technology makers should increase transparency

Based on the detailed tussle analysis that was performed for 8 research projects in [5] we conclude that the Network Security functionality creates many spillovers to other networking functionalities, and especially the Transmission one. The reason traces back to the original design goals of the ARPAnet, which is the precursor of the Internet. These are: 1. Interconnection of Existing Networks: develop an effective technique for multiplexed utilization of existing interconnected networks rather than imposing a new unified global network that could become obsolete later 2. Survivability: the entities communicating should be able to continue without having to reestablish or reset the high level state of their conversation. 3. Support for multiple Communication Service Types: the Internet should support, at the transport layer, a variety of applications that could be distinguished by differing requirements for such things as bandwidth, latency and reliability. 4. Support for a variety of Physical Networks: to incorporate and utilize a wide variety of network technologies. 5. Distributed Management: Internet resources should be able to be operated and managed by distributed stakeholders. 6. Cost Effectiveness: desire for efficient use of network resources. 7. Simple Host Attachment: desire for keeping the complexity of host protocol stacks low, so that deployment was not hindered. 8. Resource Accountability: desire for monitoring the usage of network resources. As Clark [22] mentions: This set of goals might seem to be nothing more than a checklist of all the desirable network features. It is important to understand that these goals are in order of importance, and an entirely different network architecture would result if the order were changed. For example, since this

http://www.cidr-report.org/as2.0/ Edge ISPs have the incentive not to conform to the CIDR (Classless Inter Domain Routing) standard by announing disaggregated BGP routes in order to perform traffic engineering. This behavior increases the size of the routing tables and results in increased cost for the Transit ISPs who must upgrade their routers. 23 North American Network Operators' Group
22 21
Public
network was designed to operate in a military context, which implied the possibility of a hostile environment, survivability was put as a first goal, and accountability as a last goal. [...] While the architects of the Internet were mindful of accountability, the problem received very little attention during the early stages of the design, and is only now being considered. An architecture primarily for commercial deployment would clearly place these goals at the opposite end of the list. 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. Thus, technology makers (like research projects) should be given incentives to deal with security issues (in the broader sense) in a more systematic way, without making hard assumptions on the stakeholders behaviour or creating spillovers to other functionalities. Focusing on the actual user requirements and providing enough flexibility will increase the adoption chances of a particular technology. A nice example of a promising technology for making senders accountable for the congestion they cause is the Congestion Exposure (ConEx) protocol24. It requires a sender to inform the network about the congestion that each packet is expected to cause; otherwise the packet will be dropped with high probability before reaching its destination. Furthermore, the reputation systems that have been previously described are security mechanisms that provide feedback loops for all participants and balance trust and trustworthiness. Similarly, monitoring mechanisms can help in verifying that an entity has considered the suggestions of the other party/parties participating to the session, following the design for choice principle. Thus, assuming that enough competition exists, monitoring can also act as an incentive mechanism for providers to follow the Exposure of list of choices recommendation (which is part of the Design for Choice design principle).
Recommendation 6: Policy makers should encourage knowledge exchange and joint commitments
Confirming the importance of engaging all stakeholders into the process of designing Future Internet architectures, as was stated in Dewandres key-note speech in the Oxford SESERV Workshop25, policy makers should encourage the creation of multi-disciplinary teams. Technologists, collaborating with social researchers, economists and policy experts allow the exchange of valuable information and result in technologies with greater chances in succeeding. A recent success story is the collaboration of a biologist with computer scientist, which revealed that the behavior of harvester ants as they search for food mirrors the TCP protocol that control traffic on the Internet26. Quoting Prof. Prabhakar "Ants have discovered an algorithm that we know well, and they've been doing it for millions of years [] had this discovery been made in the 1970s, before TCP was written, harvester ants very well could have influenced the design of the Internet." Given that the absence of a common vocabulary increases the time it takes for the participants to achieve a common understanding of the main challenges and agree on possible countermeasures, participants should be patient and open-minded. Another important aspect is the exploitation of synergies amongst research projects as well as projects and the industry. Given that the Internet is a complex ecosystem of technologies and socio-economic interests of various stakeholders, a more systematic approach is needed in order to have a positive effect in the future Internet architecture. The main reason is that there are limited synergies; new technologies are proposed and evaluated, but these rarely become standardised or be extended by other initiatives. We welcome further extensions to technologies that have been proposed by finished projects, as in the case of OPTIMIS which further developed the WSAG4J

http://datatracker.ietf.org/wg/conex/ http://www.seserv.org/panel/conferences-webcasts#dewandre 26 Stanford biologist and computer scientist discover the 'anternet', available online at http://engineering.stanford.edu/news/stanford-biologist-computer-scientist-discover-anternet
25 24
Public
standard; a framework for managing SLAs that came from the SMART LM project27. Furthermore, usually there are limited interfaces to or documentation on the complementary technologies. A standalone technology is less likely to deal with stakeholders interests successfully, making it less attractive to those that could adopt it. For example, monitoring technologies are considered important for providing QoS-aware network services across ISPs. Another important aspect of collaborations is joint commitment on the success of a partnership. The need for several technologies in order to achieve the necessary functionality means that more than one stakeholder will have to move forward at the same time (each one adopting a subset of those technologies). Large Integrated Projects and recent Public Private Partnership initiatives (PPP) are promising directions towards the goal of positive impact on the Internet.
4.2.
Social SESERV Recommendations
In this section the 22 social SESERV recommendations from throughout the report have been regrouped into several top-level themes to show how they are related to each other in the FI Ecosystem. (Note that several recommendations appear in more than one grouping). Research Project Design / Project Development Several of the recommendations from throughout this report focus on allowing time for different disciplines to mesh during projects, to set an appropriate pace, to have flexibility in organizational structures and funding, and to consider issues of sustainability.
RECOMMENDATION 1 Demand clear time in first months of projects allocated for conversation between partners from different disciplines to accomplish true multidisciplinary collaboration and dedicate resources to this. RECOMMENDATION 2 Do not concentrate too much on having fast-moving goals in the first stage of projects; allow for additional iterations. Do not initially evaluate the project solely on fast activity or product output, but on other indicators such as uptake or usability. RECOMMENDATION 4 Create flexible structures and funding incentives to facilitate multidisciplinary teams coming together for a problem focused effort or an area study, such as promoting projects which specifically include stakeholders from all appropriate areas. RECOMMENDATION 7 Fund longer projects, or fund second rounds/follow-ups. There needs to be a mechanism or funding model to go from a technical proof of concept through to a real product, with the kind of iterative development/release cycles often found in mainstream, commercial technology developers. RECOMMENDATION 8 Provide funding for a champion after the project has ended to stay engaged with the community to create continuation. Alternatively, find caretakers in communities and support them with funding and time. Let the users take-over and make the process bottom-up with some help.

27
SmartLM - Grid-friendly software licensing for location independent application execution, http://www.smartlm.eu/
Public
These recommendations are aimed primarily at a mix of technology developers (1, 2, 4), funding bodies (7, 8), project managers (1, 2, 4, 8), although there are also points aimed at communities of technology users/participants (8). Some of these recommendations are difficult to implement in current conditions of tight budgets and funding austerity (such as allowing extra start-up time for projects or to provide support beyond the end of a project), but the evidence seems clear that, particularly in the case of the up-front investments, small amounts of extra time and resources can greatly increase the likelihood of overall project success, thus protecting the investment in the project.
Users/Participants Experiences and Perspectives

The next set of recommendations has to do with one of the major themes of SESERV: the importance of considering the centrality of the Internet participant (i.e. user) in successful Future Internet technologies. The importance of understanding the people who will make use of technology and leverage technologies for new uses was a consistent theme throughout the project. At all the workshops and FIA events, at all the focus groups, and in many of the documents and video interviews posted online, the user has a concept underlies much of the current thinking across the board. The challenge, however, is to move beyond the idea of the user as problem or barrier, and instead to consider the people who participate in using technology as key stakeholders in the design of the Future Internet. RECOMMENDATION 6 Continue to support technology projects which involve skilled user experience (UX) design and user-oriented researchers as a core part of multidisciplinary teams. RECOMMENDATION 9 Dont let the ease of collecting user data be done to such an extent as to let the user feel under surveillance or under threat (or more simply put off). RECOMMENDATION 11 Create better methods for informing users what their data is worth, and what they are getting in exchange for sharing it (and what the consequences of using services is). RECOMMENDATION 13 Look at what users actually do, how they interact and what they expect. Users need to be included, not only as significant FI stakeholders, but also because without user-involvement, there can be no empirics and therefore no science. RECOMMENDATION 15 QoE not QoS is what matters; privacy and trust are concepts that end-users are better qualified to determine. Look at what users actually want and the form of the data they use, not the content of the data itself. Its user experience that matters, not what technology is used to deliver what data. RECOMMENDATION 20 Research and innovation directions do include issues which have been identified as strategic. It is time to start to incorporate the findings of current projects in shaping what should be the focus in Horizon2020 and beyond, as well as the mid-term review of the DAE. For the Better Society arm of Horizon2020, how users actually use services and applications, as well as what that will do to the infrastructure needs to be examined carefully. Without user involvement, though, there is no empirical evidence of what really happens in the Internet.
This group of recommendations is of potential interest to technology developers (6, 9, 11, 13, 15) and project managers (6, 13). Funding bodies (6, 20) have a role to play in supporting projects with a user focus, and governments (9, 11, 20) have a key role to play in developing regulations and
Public
frameworks that support users as key stakeholders in the Future Internet. Citizens and civic society advocates (9, 11, 20) also have a role to play here in advancing the conversation. Technology providers and businesses (9, 11, 15) are also important, since they provide the networks and systems that will implement strategies and policies affecting users and uses.
Internet Data
Data is a key source of business value, especially in the current age of big data analytics, and data about users and uses is both a source of business value and of potential problem if data security is allowed to be compromised or data is used for purposes which are considered unacceptable. Also, the volume of data flowing over the network is the source of many of the contentions and tussles discussed in great detail in D2.2. From the social point of view, understanding how data is being used and how better experience is being delivered are key issues. RECOMMENDATION 10 Increase transparency about how data is being used, and make understandable and clear choices available to the public (e.g. simple frameworks more like Creative Commons rather than 10-page legal documents). RECOMMENDATION 12 Understanding the forms and uses of data is often more important than just understanding the size or structure of the data itself. The static aspects of data management (storage and search/retrieval) are relatively easy to manage; the dynamic aspects (data transmission to support particular real or perceived Quality of Experience) are where the real problems lie.
These recommendations are of particular interest to citizens and civic society advocates (10), technology providers (10, 12), and businesses (10, 12).
Regulation and Public Policy

The importance of taking social issues into account when deciding public policy and setting regulatory frameworks into motion cannot be underestimated. At the moment, different stakeholders often only have a limited understanding of the goals and limitations of other stakeholders, which impedes successful policy and regulation. For instance, the user view of network congestion (which might be seen simply as an annoyance) is very different from the ISP view of network congestion (for whom it is a core business challenge), but unless these two parties are both part of discussions on how to regulate congestion and set policy to increase network usage, the resulting regulations are more likely to reach sub-optimal results.
RECOMMENDATION 16 Focusing on commercially-based cross-border content is not enough. Much of the content currently being shared is of little commercial value but is straining the network. The debate over net neutrality should take into account both commercial and social factors. The Digital Agenda would do well to look to users and how they use content to be able to define urgently needed regulation in this area.
Public
RECOMMENDATION 17 It is vital to involve all interested parties paying special attention to the changing nature of the FI ecosystem and associated stakeholders. The FI will become more and more IoT-like, built on cloud-like shared facilities. Legislation and regulation need to keep pace with the ever-increasing pace of user-driven change. A common language and terminology to facilitate multi-disciplinary debate will be key. RECOMMENDATION 19 Investment in infrastructure is not enough, and may not even keep pace with projected traffic. There is already a need to optimise usage rather than let traffic spiral out of control. Further, rural and last-mile provision may need careful monitoring by suitably empowered industry watchdogs to ensure end-to-end QoS irrespective of user type. Ultimately, though, the business model around the virtuous cycle may well need revision. RECOMMENDATION 20 Research and innovation directions do include issues which have been identified as strategic. It is time to start to incorporate the findings of current projects in shaping what should be the focus in Horizon2020 and beyond, as well as the mid-term review of the DAE. For the Better Society arm of Horizon2020, how users actually use services and applications, as well as what that will do to the infrastructure needs to be examined carefully. Without user involvement, though, there is no empirical evidence of what really happens in the Internet. RECOMMENDATION 22 There is an urgent need to review actual usage alongside the focus on the optimisation of resource exploitation. Individual users develop their own concepts of what they are prepared to share and how it should be protected. Usage projections suggest that they are rapidly becoming a concern if not completely unsustainable. It is unwise though to try to fix what is worthwhile (or cultural) and what is not.
Stakeholders from across the board have an interest in the regulatory and public policy aspects of the Future Internet, but engaging them all in the debate can be a challenge. Governments and regulatory bodies are interested in all of these issues (16, 17, 19, 20, 22), but these are also of central concern to users (16, 17, 22), technology providers (17, 19, 22), and content businesses (16, 22).
Transparency and Trust

Trust (and the transparency which underpins and inspires trust) has been a common theme of discussions about networking technology for decades, yet it remains the source of on-going challenges for the Future Internet. Ranging from trust within development teams to public trust in the network, these recommendations reflect the position taken by IBMs Hartman during the SESERV workshop in Brussels: that trust is asymmetrical and fragile it takes a long time to build, a moment to break, and is hard or even impossible to repair [3]. RECOMMENDATION 5 Create teams built on mutual trust by establishing expertise, managing expectations from different partners, and establishing boundaries of which aspects of the project are open to change, and which are fixed.
Public
RECOMMENDATION 10 Increase transparency about how data is being used, and make understandable and clear choices available to the public (e.g. simple frameworks more like Creative Commons rather than 10-page legal documents). RECOMMENDATION 14 There need to be transparent technologies and new business models to ensure all stakeholders in the network are treated fairly in the context of user expectation that the technology is transparent and QoE is the most important factor. RECOMMENDATION 18 More direct involvement of end-users in the design and validation of trust and security issues, along with some flexibility in allowing users to set their own boundaries. Access to appropriate risk and security expertise should be provided, including ensuring sufficient resource is available to handle alerts and attacks. Some incentives may be required as we begin to understand how to maintain and restore trust. Ultimately though transparency rather than legislation is needed above all.
Trust in the Future Internet involves all stakeholders at some level, but the recommendations here will be of particular interest to project managers (5, 18), governments and regulatory bodies (10, 18), businesses (10, 14), technology developers (5, 18), and technology providers (10, 14, 18).
Citizenship, Awareness, and Education

The final group of recommendations relates to the public at large, and the responsibility of more members of the public to become knowledgeable stakeholders in the Future Internet conversation. Whether that involves students becoming trained in how to bridge the gaps between technology developers and social expertise, or end-users becoming better educated consumers of how their data is being used and what risks that entails, more people need to make the move from being passive users into active participants in the Future Internet ecosystem. RECOMMENDATION 3 Target training at identifying students with skills that can be developed to become bridgers and tie this to the economic benefit of this for both the individuals and for society. RECOMMENDATION 11 Create better methods for informing users what their data is worth, and what they are getting in exchange for sharing it (and what the consequences of using services is). RECOMMENDATION 21 Providing appropriate support and education to increase digital awareness will enable users to make appropriate and informed decisions about security and risk, increasing their levels of trust. In addition to user involvement, it is important though to introduce ethics into the development of infrastructures. Once more, though, its important to look at what users are actually doing, and their expectations; they are becoming increasingly sophisticated in what they do and what they demand.
These recommendations are all of interest to citizens and technology users (3, 11, 21). In addition, funding bodies can prioritize support for new training schemes (3), which may involve embedding students with technology developers and providers. Businesses, governments, and civic society advocates all have a role to play here as well, particularly with regard to providing clearer information to the Internet-using public (11, 21).
Public
5. Conclusions
This whitepaper summarises the general approach as adopted by WP2 and WP3 in organising and analysing focus group discussions on a range of socio-economic topics. Specific conclusions from the various groups are reported in individual, targeted documents [5], [6]. Furthermore, the SESERV framework (called Tussle Analysis) is described and demonstrated, which helps technology developers and policy makers to understand the complex interplay of technology and economics in the Internet. The rationale behind running focus groups as opposed to any other method arose from the observation at the SESERV Oxford workshop that there was an urgent need to adopt a multidisciplinary approach to discussion. Focus groups are specifically geared towards an examination of how ideas and concepts develop in a given context. A focus group approach was an ideal method to encourage such cross-disciplinary discussion. As described in the preceding sections, the focus group methodology found in the literature was reviewed and either applied directly to the SESERV focus groups, or modified in some small detail as outlined to suit the topics and group composition available to SESERV. WP2, focusing on economic issues, adopted a structured approach, seeding discussion on the basis of a Challenge 1 project presentation to describe one possible solution to the specific issues under debate. WP3 by contrast used a less formal approach, using the occasional question to spark off discussion. In both cases, conversations were lively and generated a significant set of concepts and ideas which would be worthwhile pursuing and which are developed in the corresponding deliverables in the respective work packages. The Tussle Analysis framework is composed of a methodology for evaluating Internet technologies (called tussle analysis) and a set of taxonomies. The latter include: a) An extensive taxonomy of Internet functionalities, which covers both aspects of how services are being hosted (cloud-related functionalities) and their actual delivery (networkrelated functionalities). b) A generic classification of Internet stakeholder into seven high-level stakeholder roles, where each one is further decomposed into more detailed instances. This methodology 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. The idea is that 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. The outcomes of all bilateral discussions, wider focus groups and meetings resulted in a set of six economic recommendations to research projects, providers and policy makers for successfully redesigning and configuring Future Internet technologies. These are: 1. Technology makers should understand major stakeholders' interests. 2. Technology makers should be neutral. 3. Technology makers should explore consequences and dependencies on complementary technologies. 4. Technology makers and Providers should align conflicting interests through incentive mechanisms. 5. Technology makers should increase transparency. 6. Policy makers should encourage knowledge exchange and joint commitments.
Public
The project also had a set of 22 social recommendations, detailed above, which fall into six broad categories: 1. Research Project Design / Project Development 2. Users/Participants Experiences and Perspectives 3. Internet Data 4. Regulation and Public Policy 5. Transparency and Trust 6. Citizenship, Awareness, and Education
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(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] SESERV Deliverable D1.4: Second year report on Scientific Workshops . [4] The SESERV Coordination Action: First Report on Social Future Internet Coordination Activities. SESERV Deliverable D3.1, pp. 1-67, September 8, 2011. [5] The SESERV Coordination Action: Final Report on Economic Future Internet Coordination Activities. SESERV Deliverable D2.2, September 2012. [6] The SESERV Coordination Action: Final Report on Social Future Internet Coordination Activities. SESERV Deliverable D3.2, August 2012. [7] Kitzinger, J. (1994) The methodology of Focus Groups: the importance of interaction between research participants in Sociology of Health & Illness, Vol 16, No 1, pp 103-121. [8] Morgan, D. L. (1988) Focus groups as qualitative research, SAGE Publications, London. [9] Merton, R.K., Kendall, P.L. (1946) The focused interview in American Journal of Sociology, Vol 51, pp 541-549. [10] Cronin, A. (2001) Focus Groups pp 165-177 in Researching social life Gilbert, N. (ed), SAGE Publications, London. [11] Bloor, M., Frankland, J., Thomas, M., Robson, K. (2001) Focus Groups in Social Research, SAGE Publications, London. [12] N. Thi-Mai-Trang, On The Way To a Theory for Network Architectures, World Computer Congress, Network of the Future Conference, Brisbane, Australia, September, 2010 [13] E-communications household survey, Special Eurobarometer 381, available online at http://ec.europa.eu/public_opinion/archives/ebs/ebs_381_en.pdf [14] N. Dewandre: The Societal Interface of the Digital Agenda for Europe, Keynote address at the Oxford/SESERV Workshop, http://www.seserv.org/panel/conferences-webcasts#dewandre, 2011
Public
[15] Smithson, J. (2000) Using and analysing focus groups: Limitations and possibilities in International Journal of Social Research Methodology, Vol 3, No 2, pp 103-119 . [16] Webb, C., Kevern, J. (2000) Focus groups as a research method: a critique of some aspects of their use in nursing research in Journal of Advanced Nursing, Vol 33, No 6, pp 798-805, Blackwell, Oxford. [17] Kitzinger, J. (1993) Understanding AIDS: researching audience perceptions of Acquired Immune Deficiency Syndrome pp 271-304 in Getting the Message Eldridge, J. (ed), Routledge, London. [18] Godet,M.,Actors moves and strategies: the MACTOR method, Futures, 1991, pp.605-622 [19] Godet, M., From Anticipation to action. A handbook of strategic prospective, Unesco Publishing, 1994, Paris, France [20] D. Papadimitriou, T. Zahariadis, P. Martinez-Julia, I. Papafili, V. Morreale, F. Torelli, B. Sales, P. Demeester , Design Principles for the Future Internet Architecture, The Future Internet Lecture Notes in Computer Science, pp 55-67, ISBN 978-3-642-30240-4, Springer, Berlin Heidelberg, Germany, Vol. 7281, May 2012 [21] A. Odlyzko, "The History of Communications and its Implications for the Internet" 2000. Available at SSRN: http://ssrn.com/abstract=235284 [22] D. Clark. 1988. The design philosophy of the DARPA internet protocols. SIGCOMM Comput. Commun. Rev. 18, 4 (August 1988), 106-114. DOI=10.1145/52325.52336 http://doi.acm.org/10.1145/52325.52336 [23] The ETICS research project: Business and legal framework for Network Interconnection, Deliverable D3.1, 2010, available online at https://bscw.ictetics.eu/pub/bscw.cgi/d18622/D3.1%20Business%20and%20legal%20framework%20for%20N etwork%20Interconnection%20%28v1%29.pdf [24] [R. B. Myerson and M. A. Satterthwaite. Efficient mechanisms for bilateral trading. Journal of Economic Theory, 29:265281, 1983.
Public
7. Abbreviations
ASQ BGP CPU DPI FG FI FIA ICT ISP MPLS PDU PPP QoE QoS SLA SNS TAFI TCP UBM VoIP WP Assured Quality of Service Border Gateway Protocol Central Processing Unit Depp Packet Inspection Focus Group Future Internet Future Internet Architecture Information and Communication Technology Internet Service Provider Multi-Protocol Label Switching Protocol Data Unit Public Private Partnership Quality of Experience Quality of Service Service Level Agreement Social Networking Site Towards A Future Internet Transmission Control Protocol Unified Business Modeling Voice over IP Work Package

Using Focus Groups and Tussle Analysis Methodology For Understanding Socio-Economic Aspects of The Future Internet

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Using Focus Groups and Tussle Analysis Methodology For Understanding Socio-Economic Aspects of The Future Internet

Transféré par

Droits d'auteur :

Formats disponibles

Using Focus Groups and Tussle Analysis Methodology for Understanding Socio-Economic Aspects of the Future Internet v1.

0 Seventh Framework CSA No. 258138

Socio-Economic Services for European Research Projects (SESERV)

The SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

2. Focus Groups: General Methodology

Copyright 2012, the Members of the SESERV Consortium

Running the Focus Groups

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Details of Group Composition

2.5. Should Focus Groups Involve Strangers or Pre-existing Social Groups?

Copyright 2012, the Members of the SESERV Consortium

The Stakeholders for the Focus Group

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Audio and Video Recording

Length and Payment Length

Copyright 2012, the Members of the SESERV Consortium

Tools and Techniques Pre- and Post-Group Self-Completion Questionnaires

Discussion List of Issues

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Conclusions on Focus Group Methodology from SESERV

EXPLOIT LOCAL CONTEXT

Copyright 2012, the Members of the SESERV Consortium

3. Introducing and Applying the Tussle Analysis Methodology

Figure 1: Basic technology cycle due to conflicting socio-economic interests

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Figure 2: Tussle evolution due to instability and externalities

Copyright 2012, the Members of the SESERV Consortium

The tussle analysis methodology

Copyright 2012, the Members of the SESERV Consortium

Figure 4: A Taxonomy for Internet Functionalities More specifically:

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Figure 6: A detailed view of tussle analysis methodology

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Economic SESERV Recommendations

Recommendation 1: Technology makers should understand major stakeholders' interests

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Recommendation 5: Technology makers should increase transparency

Copyright 2012, the Members of the SESERV Consortium

Copyright 2012, the Members of the SESERV Consortium

Social SESERV Recommendations

Copyright 2012, the Members of the SESERV Consortium

Users/Participants Experiences and Perspectives

Copyright 2012, the Members of the SESERV Consortium

Regulation and Public Policy

Copyright 2012, the Members of the SESERV Consortium