Getting Started‎ > ‎

A Set of Seven Economic Challenge Areas for the Future Internet

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.


Comments