# Arithmetic Study about Efficiency in Network Topologies for Data Centers
## 1 Introduction
Hence, this measurement has positive implications for lower values, such as that a small value results in faster regular operations and maintenance (O&M) due to the relative straightforwardness of the algorithm being employed. Therefore, this is the reason why the average number of links per node is considered as a measure of simplicity of a certain data center topology in this paper. Consequently, the metrics applied to performance of a given data center topology in the context of this paper are measured as the average number of hops between any pair of nodes within that topology. In this sense, it is to be considered that the lower the value, the better the performance, as reaching a particular destination node from a given source node will be shorter in average, meaning that pairs of nodes are a smaller number of hops away on average. Likewise, the metrics applied to simplicity of a particular data center architecture in the context of this manuscript are measured as the average number of links per device, either switches or nodes, hence giving consideration to all devices within a given topology. In this sense, it is to be taken into account that the lower the value, the simpler the topology; thus, traffic forwarding will be carried out by a shorter algorithm, which implies faster processing times. This way, the units to measure performance in this context are adimensional, as the average number of hops between nodes does not imply any physical measurement units, such as time in seconds or length in meters. Analogously, the units to measure simplicity in this context are also adimensional, as the average number of links per device does not involve any physical measurement units at all. Therefore, the metrics forthe coefficient proposed to obtain balance between performance and simplicity will also be adimensional, as the metrics of both its parameters are adimensional as well. Furthermore, as both parameters display better results with lower values, it yields that the lower the coefficient value, the better. On the other hand, the values obtained for the coefficient regarding many of the most commonly used topologies in data center topologies will be calculated and compared in further sections. The main merit of this approach of crafting this coefficient is to have an easy way to obtain an approximation of performance for a network topology within a data center, as both factors to calculate it are pretty straightforward to obtain. This coefficient does not need to be seen as a key parameter, but it is just another parameter that may be used as a sort of tie-breaker when other variables such as throughput or security offer different solutions. With respect to the demerits, this coefficient does benefit non-redundant topologies over redundant ones, as the lower the number of links, the better is the obtained outcome. Hence, the condition of redundancy must be imposed prior to using this coefficient. Regarding the motivation of this paper dedicated to network topology data centers, the following considerations have been made:Define an easy metric based on arithmetic calculations to be applied to classify network topologies of data centers. * Craft such a metric as a combination of performance and simplicity of a network topology data center. * Impose redundant layouts as a restriction to find out that metric so that it does not apply to non-redundant designs. * Provide that metric as a complementary measurement to the most common parameters typically found in data centers, such as throughput or latency. * Create a coefficient related to data centers that is not focused on energy efficiency, as is the case for the existing coefficients in this field. The organization of the rest of the paper is as follows: Section 2 introduces some topology designs for data center. Next, Section 3 exposes some related work about network topologies for data centers. Then, Section 4 presents the coefficient proposed for these designs. After that, Section 5 develops some typical use cases.