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.
3.13 Summary
This chapter outlined many of the key topics around network technology, so far as they relate to infrastructure edge computing, with the aim of providing the reader with a foundation from which to build upon other network‐related topics throughout the rest of this book. The terminology and concepts described in this chapter will be used frequently throughout this book in many chapters.
One key topic that was introduced was the STF metric. This metric allows an infrastructure edge network operator to understand the effectiveness of their network and, therefore, its real value. Although this metric could have been described in a separate chapter, it is primarily a metric that describes an infrastructure edge computing network and so it was included here rather than not.
In the next chapter, we will explore data centre technology in order to provide the context to fully understand the impact of infrastructure edge computing on data centre technology, operations, and other related topics. These topics will be explored in later chapters, using the next chapter as a base.
References
1 1 ISO/IEC. ISO/IEC standard 7498‐1:1994 [Internet]. 1994 [cited 2020 Sep 30] Available from: http://standards.iso.org/ittf/PubliclyAvailableStandards/s020269_ISO_IEC_7498‐1_1994(E).zip
2 2 Richards, H. Edsger Wybe Dijkstra [Internet]. 2019 [cited 2020 Sep 30]. Available from: https://amturing.acm.org/award_winners/dijkstra_1053701.cfm
3 3 Amazon Web Services. AWS Direct Connect [Internet]. 2020 [Cited 2020 Sep 30]. Available from: https://aws.amazon.com/directconnect
4 4 Microsoft Azure. Azure ExpressRoute [Internet]. 2020 [cited 2020 Sep 30]. Available from: https://azure.microsoft.com/en‐us/services/expressroute
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив