The troubled journey of QoS: From ATM to content networking, edge-computing and distributed internet governance

Abstract

Network Quality of Service (QoS) and the associated user Quality of Experience (QoE) have always been the networking "holy grail" and have been sought after through various different approaches and networking technologies over the last decades. Despite substantial amounts of effort invested in the area, there has been very little actual deployment of mechanisms to guarantee QoS in the Internet. As a result, the Internet is largely operating on a "best effort" basis in terms of QoS. Here, we attempt a historical overview in order to better understand how we got to the point where we are today and consider the evolution of QoS/QoE in the future. As we move towards more demanding networking environments where enormous amounts of data is produced at the edge of the network (e.g., from IoT devices), computation will also need to migrate to the edge in order to guarantee QoS. In turn, we argue that distributed computing at the edge of the network will inevitably require infrastructure decentralisation. That said, trust to the infrastructure provider is more difficult to guarantee and new components need to be incorporated into the Internet landscape in order to be able to support emerging applications, but also achieve acceptable service quality. We start from the first steps of ATM and related IP-based technologies, we consider recent proposals for content-oriented and Information-Centric Net

QoS‐aware IoT networks and protocols: A comprehensive survey

“…IoT architectures that are based on only cloud computing paradigm can introduce too much latency in application responses, as well as heavier loads on network traffic and servers. 5,33 By bringing the computation and storage resources closer to the network edge, and enabling decentralized processing, the latency of responses reaching the end-users as well as the traffic loads can be alleviated. This is the main idea behind introducing Fog computing paradigm, which aims to enable more efficient and cost-effective solutions for IoT applications.…”

“…[1][2][3][4] One of the ideas behind the Edge/Fog computing paradigm is to improve the QoS, as well as the quality of experience (QoE), for the core Internet infrastructure by decentralizing and bringing the computation closer to the edge in order to reduce the response delay to end-users, relieve the traffic in the network core, and reduce server loads. 5 Hence, designing efficient Edge/Fog computing-based QoS-aware solutions for IoT applications will be crucial for the success of the IoT paradigm.…”

“…The scalability issue, along with other challenges such as efficient integration and interoperability of heterogeneous web objects, security and privacy concerns, and especially adequate and timely access of web services in an ecosystem of billions of smart objects, poses a deterrent for the development of self‐governing intelligent systems that can provide QoS guarantees 1–4 . One of the ideas behind the Edge/Fog computing paradigm is to improve the QoS, as well as the quality of experience (QoE), for the core Internet infrastructure by decentralizing and bringing the computation closer to the edge in order to reduce the response delay to end‐users, relieve the traffic in the network core, and reduce server loads 5 . Hence, designing efficient Edge/Fog computing‐based QoS‐aware solutions for IoT applications will be crucial for the success of the IoT paradigm.…”

Blockchain-Based SLA Management in the Context of IoT

“…SLA conformance in the context of IoT can be a challenging task [6]. That is, many IoT scenarios cannot bear compromising service quality; and therefore, it is essential to rigorously maintain a high degree of SLA compliance by employing an effective monitoring and enforcement mechanism.…”

“…In current practice, cloud providers are commonly assumed for holding the responsibility for typical SLA lifecycle management, such as SLA initiation, service monitoring, and contract enforcement [5]. However, when considering several important factors, such as deliberate corruption, misconduct, opacity, conflict of interest, single point of failure, and incompetent awareness of end-to-end IoT ecosystem requirements, we argue that no single party should solely control SLA lifecycle management [6].…”