Читать книгу Understanding Infrastructure Edge Computing - Alex Marcham - Страница 62

The ability of the infrastructure edge computing network to serve traffic is a key measure of its value, and so high targets, such as serving 75% of all traffic received from the access network, are common. Although these targets may seem high, the key to achieving them is defining a realistic scope and an understanding of real user needs; once the underlying infrastructure is established, this is typically a task for the tenants of the infrastructure edge computing network such as content providers. These entities must then optimise the software resources such as application instances or pieces of specific content present on the infrastructure edge network in order to maximise all the achievable benefits.

Three possibilities exist when an infrastructure edge computing network receives traffic. It can serve the traffic; it can transit the traffic to a destination which it believes can serve it; or it can drop the traffic, which is a failure. The latter may occur where the infrastructure edge computing network has no route to any destination which it believes will be able to serve the traffic, and so the traffic is just dropped instead. This is of course suboptimal and to be avoided wherever possible by all parties. In an ideal scenario, the infrastructure edge computing network performs measurably better than its centralised counterpart in terms of lower latency and the reduced cost of data transportation and introduces as few cases of lower performance as possible; where traffic cannot be served by the infrastructure edge network itself, the network should not significantly decrease performance by transiting that data to a destination such as to a regional data centre compared to the alternatives.

There is a simple metric used to calculate the value of an infrastructure edge computing network in the form of serve transit fail (STF). It can be calculated as follows over a given period of operations:

1 Compare statistics from the ingress (traffic that is entering the infrastructure edge network from any of its interconnected access networks) and egress (traffic exiting the infrastructure edge network that is transiting from those same access networks) data flows collected over a period of time such as a week or longer to provide a realistic view of network operations.

2 Calculate the proportion of ingress to egress traffic as described previously. In this example, we will use the following figures for this step, which have been chosen just for their simplicity. We can see that with these figures, 90% of the ingress traffic was either served or failed at the infrastructure edge network, and the remaining 10% was transited to another destination.Ingress traffic: 100 GBEgress traffic: 10 GB

3 At this stage, our infrastructure edge computing network has a very high STF of 0.90. This is encouraging, although we do not have the full picture yet. Next, we must then subtract the impact of any failures to deliver traffic from this metric. Because in this example we are measuring traffic only in terms of size and not in terms of individual session requests, we must be able to coarsely estimate the impact of a failure by the amount of traffic that, if the failure had not occurred, would have been served in response to the failure either on or off edge.For this example, we will estimate that each failure would have generated on average 50 MB of traffic had it not failed. In a production network, this estimate would be generated based on the type of traffic observed across the network and, where possible, the specifics of the failures themselves; but this suffices for now.We can arrive at a rough estimate for this example of the number of failures by using a combination of Internet Control Message Protocol (ICMP) destination unreachable messages, which are returned to an endpoint by an endpoint within the infrastructure edge computing network, and by application‐level error responses which indicate a particular missing resource or piece of content within the edge.

4 We then need to subtract the impact of these failures from the current STF metric. For the sake of simplicity in this example, we will continue to use the overall volume of traffic to do this. If we estimate that 100 failures occurred, each averaging 50 MB of traffic, this requires us to subtract 5 GB (100 × 50 MB) from our 0.90 STF, which in this example is equal to 90 GB. This leaves us with 0.85 (90 – 5 GB) for our STF. We could weight failures more heavily to reflect their impact on the user experience, but for this example we will leave them neutral.

5 The STF for the infrastructure edge computing network over the measurement time is 0.85. With this information, the network operator can tune the network as required over time.

There are multiple potential ways that the STF metric could be calculated. Numbers of application sessions could be used in place of traffic size measurements and estimates of the impact of failures; however, for the sake of simplicity, we will use the method described previously in this book. Other ways of calculating this and similar metrics to determine the real effectiveness of an infrastructure edge network are being explored across the industry, but the aim of all of them is the same: to determine whether a particular instance of infrastructure edge computing is helping or hindering the internet.

Consider the example of two infrastructure edge computing networks. One has achieved a high STF, and the other has not. With all other things being equal, the higher STF indicates a far more valuable and effective infrastructure edge computing network compared to one with a lower STF. For each of the networks of interest, the STF would be calculated as in the previous example, taking care to use the same method of calculation so that the comparison is as fair as possible. The metric figure is not tied to a specific scale of infrastructure edge computing network or a specific set of users or use cases; it provides a relatively neutral measure of the effectiveness of the network’s ability to provide benefit.

The STF metric provides the infrastructure edge computing network operator with a useful figure by which to judge the effectiveness of the overall system. It is reasonable that a minimum acceptable STF then be used to determine whether a specific infrastructure edge computing implementation is worthwhile or if it needs to be improved to reach an acceptable level of effectiveness. The realistic STF metric for a specific infrastructure edge network deployment will vary depending on its users, the types of applications they are using, and the maturity of the deployment with the acceptable metric increasing over time. Table 3.2 indicates an example of this STF metric progression:

Table 3.2 Example minimum acceptable and desired average STF metrics.

Maturity of deployment	Minimum acceptable STF	Desired average STF
0–6 months	0.10	0.15
6–12 months	0.20	0.30
12–18 months	0.30	0.50
18–24 months	0.40	0.75

However, like any such metric, STF makes a few key assumptions which should be verified for each infrastructure edge computing deployment before it is used to compare two or more deployments:

1 Traffic served by the infrastructure edge computing network is served in a way that provides a better user experience, or a lower cost of data transportation, than is possible otherwise.

2 Failures have a definite impact on the user experience and are not the result of tangential requests or unwanted traffic generated by unimportant actions or entities such as malware.

3 The transit function provided by the infrastructure edge computing network is better or as good as but not significantly worse than other options available between access to backhaul.

Another key assumption of the basic STF metric is that the value of an infrastructure edge computing network can be fairly ascertained by using traffic volume or session count as a representation of the network’s value. In some cases, the value of the infrastructure edge computing network is primarily that it enables a specific new use case, and in this scenario, it is appropriate to use a weighted STF metric that is oriented towards traffic for that specific use case, representing it overproportionally.

The STF metric will be used later in this book during use case and infrastructure edge computing network deployment examples, with specifically tuned variants of the metric used where required.