Alex Marcham - Understanding Infrastructure Edge Computing

Originally deployed during the 1990s, content delivery networks (CDNs) fully came to the fore during this period as a means to achieve several important aims. Moving stores of content closer to their intended users brought a number of key benefits to users, network operators, and content providers, ranging from the ability to provide a better user experience, reducing the growing strain on backhaul and midhaul network infrastructure, and helping to address concerns from network operators that content providers who send much more traffic than they receive were upsetting the established balance of interconnection.

During the 2020s, the trend of increasing network regionalisation will continue, enabled by the use of infrastructure edge computing. This operational and deployment methodology for moving small data centres and their associated network infrastructure out to increasingly local locations, often 15 miles or less from their end users, augments all of the other regionalisation methods employed from the 1990s through 2020. This methodology and set of technologies results in a densification of the network and data centre resources at the access layer of the network, the closest to their end users.

Infrastructure edge computing enables the architecture of the internet to progress from its origins in the ARPANET of a handful of comparatively centralised locations to a highly distributed architecture that pushes network and data centre infrastructure out into urban and rural areas, building on what began as a network with four initial hosts back in 1969 into a regionalised and densified internet that brings the capabilities of the data centre in terms of application operation, data storage, and network interconnection to potentially thousands of micro data centre locations across even a single country.

It may seem easy to look back at the design decisions made in previous architectural generations of the internet and scoff: If the benefits of network regionalisation are clear and the first steps along this path had already been taken, then why not build it out in this way from the beginning? Like all choices made during system design, there are many trade‐offs which govern whether it is feasible both technically and economically to deploy a specific level or type of infrastructure at a given time. The choices made during a particular decade as highlighted previously must be appreciated within the time and context they were made in, without judging them by what we now know in the present.

Although these changes over time to the architecture of the internet in response to the needs of both its users and its operators are remarkable, it is important to note the level of difficulty that is inherent in making any change to a complex network system. The next section describes one of the methods used by the global network engineering community to minimise the impact of any changes on other parts of the system so that changes can often be made as and when they are ready, with no need to concurrently change other links or endpoints in the network to ensure correct operation.

Any detailed discussion of network technology would be incomplete without a shared understanding of the Open Systems Interconnection (OSI) model [1]. This is an often used conceptual model which allows us to create highly interoperable, open, and scalable communication systems by categorising the technological functions required by the network into a stack of layers that are numbered from 1 to 7, each of which has a set of interfaces to communicate with its directly adjacent layers (see Table 3.1).

This model is very powerful, as by isolating a set of technological functions into a specific layer that has interfaces to talk to the layers it is directly adjacent to, changes to any one specific layer do not need to impact the operation of any other layer in the system, allowing asynchronous evolution of the entire stack of network technologies where one or more layers experience more rapid change than their neighbouring layers. An example of this can be seen with each new generation of Wi‐Fi; significant advances in speed can be achieved by changing only layers 1 and 2, without any of the upper layers being aware of the change. Consider what the situation would be like if the entire network technology stack had to be remade to accommodate a change at any layer. The stack that would result would be highly inflexible as even an isolated change would require significant work. Over time, this would become a key barrier to keeping up with the edge of technological progress and prevent open contribution to the stack by other companies or individuals, limiting innovation.

Now that the reasoning behind the OSI model has been established, we will briefly describe the functionality of each layer as it is relevant to infrastructure edge computing, and the number of each layer will be used throughout this book to quickly refer to the concepts that they represent. In this example, we will be taking the perspective of a network endpoint receiving data that has been transmitted across the network, so our progression will be from layer 1 through layer 7. When considering the process of sending data, this progress through the layers is reversed in order as data flows from layer 7 down to layer 1 to be transmitted across the physical network.

Table 3.1 OSI model layer numbers, names, and examples.

From a physical perspective, the first layer of the OSI model is at the bottom, layer 1. This layer is known as the physical layer and is responsible for encapsulating the functions of the network which are concerned with the physical transmission medium that is being used to send and receive data, whether that be radio frequency (RF), in the case of many wireless networks, copper cabling, fibre optic cabling, or another medium of choice. Although these three options are the most commonly used today, other options such as infrared (IR) light exist and are used in some specific use cases.

As well as the physical transmission medium itself, layer 1 includes the functions that are needed to encode and decode all data transmissions using that medium. For example, to send and receive data across copper cabling, an encoding scheme must be used to convert some digital application data into a sequence of physical electrical energy, which is then applied to the copper transmission medium, which carries those electrical signals to the remote end of the transmission medium where a corresponding decoding scheme reverses the process, turning these electrical signals back into the digital application data which they represented and passing this data up to layer 2 of the stack.

Layer 2 is known as the data link layer and is responsible for a few key functions of the network stack. One of these is medium access control (MAC), which is the process of determining the means by which a network endpoint may access the transmission medium to send data. In many networks, this is not as simple as merely transmitting immediately whenever layer 3 communicates to layer 2 that it has data to send. Consider a wireless network as an example: The radio spectrum used by these networks is a shared medium, where transmissions from one network endpoint are able to be received by many other network endpoints. If one endpoint were to transmit without checking to see if the “coast is clear” and transmitted at the same time as another endpoint, it is likely that both transmissions would be garbled, resulting in data being lost or being retransmitted. This is to be avoided wherever possible as it reduces the efficiency of the network considerably.