A primary task for SESERV project is to coordinate the economic dimension of Future Internet technologies, which are studied and developed by a broad set of FP7 research projects. The Annual report on studying the economic aspects of Future Internet technologies describes the coordination actions and results that have been undertaken and achieved within the first year of the project.
By following the technologies proposed by 16 european research projects we identified seven common themes of stakeholder interactions (that we call tussles) affected by those technologies.
These themes can be seen as economic challenge areas for the Future Internet and different projects may focus on different aspects of those issues, consider different set of stakeholders, or suggest different approaches for solving the same issue. The set of economic challenge areas includes the following:
|
Project
|
Tussle
|
|
CHANGE
|
Tussle
among ISPs for controlling traffic
being part of a DDoS attack near its source, using a flow management scheme across ISPs.
|
|
UNIVERSELF
|
Tussle
among ISPs for controlling traffic
being part of a DDoS attack near its source, using a reputation system for
senders.
|
|
PURSUIT
|
a) Tussle among ISPs for controlling traffic part of a DDoS attack near its source
using network level mechanisms.
b)
Threat to the ecosystem by issuing many fake requests to service directories.
|
|
STRONGEST
|
Tussle
for controlling information announced to other ISPs, e.g., about network topology, and preventing attacks by
aggregating sensitive information.
|
|
Project
|
Tussle
|
|
ETICS
|
Tussle
among ISPs controlling interconnection agreements that support QoS-enabled
inter-provider services, by allowing many configuration options and pricing.
|
|
PURSUIT
|
Tussle
among Edge ISPs, Transit ISPs and CDNs for achieving favourable
interconnection agreements, assuming that content can be cached inside the
network.
|
|
SAIL
|
Tussle among Edge ISPs, Transit ISPs and CDNs for
achieving favourable interconnection agreements, assuming that content can be
cached inside the network.
|
|
TRILOGY
|
a)
Tussle amongst an Edge and a Transit ISP for becoming peers by using MPTCP to
make such an agreement more attractive to the transit ISP.
b)
Tussle for assessment of different pricing schemes on ISPs’ cost and revenue
structure.
|
|
SMOOTHIT
|
Tussle among Edge ISPs, Transit ISPs and Brokers for
achieving favourable interconnection agreements, assuming that content can be
cached inside the network.
|
|
Project
|
Tussle
|
|
C2POWER
|
Tussle
among users who may increase the power level on their devices, and thus
consume more resources of the shared wireless spectrum, in order to reach a
distant user.
|
|
ULOOP
|
Tussle
for fair bandwidth share of an Internet connection among roaming and
non-roaming users.
|
|
P2P-NEXT
|
Tussle between users who download a file for upstream
capacity of that file’s seeders.
|
|
PURSUIT
|
Tussle
for fair bandwidth share on a common link between a set of multicast users
and a unicast user.
|
|
RESERVOIR
|
Tussle
between customers of a cloud provider on the bandwidth of the latter’s
connection to the Internet.
|
|
TRILOGY
|
Tussle
for fair bandwidth share on a common link between interactive users and users
of peer-to-peer applications.
|
|
RESUMENET
|
Tussle
between roaming users for upstream capacity of relay nodes.
|
|
BONFIRE
|
Tussle
between experimenters (End-users) for a Cloud Operator’s resources.
|
|
Project
|
Tussle
|
|
ETICS
|
Tussle
among Edge ISPs and Transit ISPs for under-dimensioned backup paths (thus
lower cost) due to absence of inter-ISP SLA monitoring mechanisms.
|
|
RESERVOIR
|
Tussle
between two Cloud providers where tasks unable to be served by one of them
receive low priority by the other in order for the latter to be prepared for
sudden workload peaks.
|
|
STRONGEST
|
Tussle between an upstream and a downstream ISPs where
the latter devotes lower effort in packet forwarding due to absence of
inter-ISP SLA monitoring mechanisms.
|
|
P2P-NEXT
|
Tussle
between Edge ISP and Content Owner in case the former caches content items to
reducing inter-domain traffic.
|
|
SMOOTHIT
|
a)
Tussle between an ISP and a Content Owner where the former caches illegally
distributed content items for reducing its transit costs.
b)
Tussle between an ASP who has deployed the SmoothIT mechanisms and an ISP,
who in absence of an end-to-end SLA monitoring mechanism, has no incentive to
provide effort enough to improve the QoE of the former’s customers.
|
|
ULOOP
|
Tussle
between an ISP and a Consumer where the latter shares/rents its Internet
connection with/to other users.
|
|
C2POWER
|
A
tussle exists between a source user and the relaying users in case the data
did not reach the destination, which may be due to a legitimate reason or a
relaying user who free-rides.
|
|
SAIL
|
a) A tussle arises between an
End-user (or a Community Infrastructure Provider) relaying traffic of another
End-User and a Community Operator (a type of broker), if the former one does
not follow the policies established by the latter, e.g. traffic
prioritization.
b) A
Network Operator and a Content Owner and a CDN provider, if the last one does
not offer the agreed content/service, or when the Network Operator/Network
Infrastructure Provider in purpose degrade the performance of the CDN service
in order to other traffic.
|
|
BONFIRE
|
Tussle between a Cloud Operator
(called Testbed provider) and End-Users (called Experimenters) in case the
latter violate the terms of service when running an experiment.
|
|
Project
|
Tussle
|
|
ETICS
|
Tussle
among ISPs for composing efficient end-to-end, QoS-aware paths (so that the
maximum number of requests can be fulfilled) even if this strategy is in
contrast to an ISP’s short-term benefit.
|
|
PURSUIT
|
Tussle
between an ISP and a (routing) Broker, where the former gives inaccurate or
partial information in order to influence the routing path or fearing that
such sensitive information will be used for espionage.
|
|
SAIL
|
a) Tussle among an ISP and a (service delivery) Broker,
where the latter’s routing decisions (content/service source selected) can
increase the former’s transit costs.
b) Tussle between an ISP and a (service delivery)
Broker, where the former gives inaccurate or partial information in order to
influence the selected cache or fearing that such sensitive information will
be used for espionage.
|
|
P2P-NEXT
|
Tussle
among an Edge ISP and an ASP, where the latter’s routing decisions
(seeders/leechers selected) can increase the former’s transit costs or
cancel-out its traffic engineering effort.
|
|
SMOOTHIT
|
Tussle
among an Edge ISP and an ASP, where the latter’s routing decisions
(seeders/leechers selected) can increase the former’s transit costs or
cancel-out its traffic engineering effort.
|
|
STRONGEST
|
Tussle
among two ISPs who send biased advertisements in order to favour the crossing
of some domains/ISPs even though other paths could be more appropriate.
|
|
C2POWER
|
A
tussle exists between a source user and each relaying user since the latter
have complete control over the rest path of the data.
|
|
BONFIRE
|
Tussle between a Broker and
Experimenters when the former’s “routing” decision (regarding the Cloud
Operator an experiment will be run) is in conflict with the user’s ability to
repeat an experiment (for achieving the same conditions and allowing the
results to be compared).
|
|
CLOUD4SOA
|
Tussle between a Broker and Cloud
Operators for controlling how End-User requests are “routed” to Cloud
Operators.
|
|
OPTIMIS
|
Tussle between a Broker and
End-Users when the former’s “routing” decision (regarding the Cloud Operator
an experiment will be run) is in conflict with the user’s interests (such as
eco-efficiency, risk and trustworthiness).
|
|
Project
|
Tussle
|
|
P2P-NEXT
|
Tussle
between Information Providers and an ISP for deteriorating QoE that customers
of the former get by using middleboxes.
|
|
PURSUIT
|
a)
Tussle between subscribers (, publishers) and service discovery brokers due
to the ability of the latter to filter/screen user requests for
content/services.
b)
Tussle between publishers (,subscribers) and service discovery brokers due to
the ability of the latter to filter/screen announcements for content/services
filters/screens for content/services.
c)
Tussle between publishers (a legitimate and a fraudulent one) for performing
‘phising’ through cache-poisoning.
|
|
SAIL
|
a) Tussle between subscribers (,publishers) and service
discovery brokers due to the ability of the latter to filter/screen user
requests for content/services.
b) Tussle between publishers (,subscribers) and service
discovery brokers due to the ability of the latter to filter/screen
announcements for content/services filters/screens for content/services.
|
|
TRILOGY
|
a)
Tussle between Information Providers (a legitimate and a fraudulent one) for
performing ‘phising’ by advertising more specific BGP prefixes.
b)
Tussle between Information Providers (an ASP and an ISP acting as an ASP as
well) for deteriorating QoE that customers of the former ASP get by using
middleboxes.
|
|
ETICS
|
Tussle
between an Information Provider, who does not buy ETICS services, and an
ETICS ISP because the latter does not invest in Best-Effort Internet
connectivity services so that ETICS services become more attractive.
|
|
ULOOP
|
a)
Tussle between end-users and Edge ISPs in hand-over to a different cell,
technology, etc.
b)
Tussle between an Edge ISP and an Infrastructure Provider for traffic
offloading in the latter’s network.
|
|
RESERVOIR
|
Tussle
between an End-User and its Edge ISP in case the former wants to connect to a
high-quality but distant Cloud Operator, whereas the latter performs traffic
shaping in order to lower transit costs and make a low-quality but local
Cloud Operator more attractive.
|
|
BONFIRE
|
Tussle between a Cloud Operator
(termed test bed provider) and experimenters when the former’s allocation of
resources, even though maximises their utilisation, is in conflict with the
user’s desire for controlling how experiments will be run.
|
|
Project
|
Tussle
|
|
PURSUIT
|
Tussle
between a service discovery broker and Subscribers due to the former’s
ability to collect and capitalize this transactional data.
|
|
RESERVOIR
|
a)
Tussle between a Content
Owner (or Security Agency) and a Cloud Operator (or Information provider depending on the
implementation) for having access to content stored by the latter in
order to identify End-Users distributing illegal content.
b)
Tussle between an ASP and a cloud provider who can keep processed data for
other purposes.
|
|
STRONGEST
|
Tussle for controlling information announced to other
ISPs, e.g., about network topology,
and preventing customer stealing by aggregating sensitive information.
|
|
C2POWER
|
Tussle
between the source user and a relaying user because the latter is capable of
copying the transferred data, and using it for a different purpose.
|
|
RESUMENET
|
Tussle
between a malice user and a Content Owner where the former illegally
capitalize the information stored in the caches of a content-centric network.
|
|
