In order to model the overall delay, we consider two sources of delay when setting the communication between the service client and the most suitable resource for the service provisioning: 1) controllers processing delay; and 2) network delay. In this section, the most important considerations regarding de delay modeling are presented.
Processing delay
Let the processing delay for each controller be the lookup time aiming at mapping the requested service into the most suitable underlying resource in its database, if any. If no suitable resource is found, the request is forwarded to its parent controller, where the procedure is repeated, and so on. In order to contemplate both heteroge neity and amount of database entries on controllers at the edge of the network, the processing time is estimated through an experiment considering several databases with the amount of entries –each entry representing one resource– varying from 103 to 106 deployed at 3 distinct devices with distinct processing capacities: 1) Intel® Core™ i5-4570 CPU @ 3.20GHz; 2) Intel® Xeon® CPU E5-2620 v2 @ 2.10GHz; and 3) ARMv7 Processor rev 4 (v7l) @ 1.20GHz. The operating system used in all devices is Ubuntu 16.04, the databases were deployed in MySQL v5.7.17, and each plotted value is an average of 20 distinct queries taking into consideration distinct attributes of the resources table, such as resource type and geographical position where it is located.
The experimental results, depicted in Figure 7.3, show that the variation in the queries processing latency according to the amount of entries in each device is linear. Therefore, through the simple linear regression model, the trend line for each device is also plotted in Figure 7.3, given by ax+b, where b is the base delay defined for each controller, a is the delay added by each entry in the controller database, and x is the database size in terms of number of entries. Therefore, for the further results presented in this chapter, 3 heterogeneous resource types in terms of computing capacity are defined by employing the 3 obtained pair-values a,b, as shown in
Table 7.1. Hence, once these linear constants are defined for each resource type, the processing delay d is given as a function of the variable x, d=f(x). Moreover, the inverse function f-1(d) can be employed in order to determine, given the maximum delay accepted in
one single controller, the maximum number of resources it is able to manage. It is worth mentioning that, albeit the capacity of each controller in terms of storage is a key factor for determining the maximum resource database size, this model does not take the storage capacity into account. This may be explained due to the fact that the main goal of the model is to assess the delay on distinct F2C control topologies and, albeit a huge number of entries in the resource database will surely demand additional storage, it is assumed, for the sake of simplicity, that the controller has enough capacity to store the complete database, with all resources information relevant to the mapping functionality. With this approach, the database size shall impact exclusively on the processing time. Indeed, the rationale behind this assumption is to show that even with extended storage capacity, the constrained processing capacity at edge resources is still a bottleneck for the deployment of a stati c control topology providing QoS-aware end-to-end communication in a scenario presenting high dynamicity.
Figure 7.3: Impact of database size on processing delay.
Table 7.1: Linear constants for processing delay estimation
Device a b
[email protected] 0.0004855 1.0986315
[email protected] 0.0010351 0.9272640
Network delay
Although the network delay is dependent on the communication technology employed on each controller network link, we assume, for the sake of simplicity, that the delay for links between 2 adjacent fog controllers –short range communication– is homogeneous and considerably lower than the delay observed on fog-cloud controllers communication –long range communication. In order to estimate the average delay for each communicat ion type, the Zenmap 6.40 network analyzer tool [103] is used to evaluate the communication delay with hosts in distinct real networks, including hosts placed in traditional cloud servers (long range communication) as well as servers at the Universitat Politècnica de Catalunya (UPC), where this work is carried out (short range communication). Considering the average delay attained in each assessed communication range, shown in Table 7.2, it is assumed the communication delay between two fog controllers to be 1ms, while the communication delay between fog and cloud controllers is assumed to be 20ms.
Table 7.2: Average network delay
Taking into account the defined parameters for the network delay model, the overall network impact must be calculated according to the control topology. On one hand, each layer added to the control topology impacts negatively on the overall latency for edge to cloud controller communication, since it requires an additional fog-fog controller communication. On the other hand, it reduces the load at each controller as well as the end - to-end delay for controllers either within the same area or in areas geographically close to each other, since it is not necessary to communicate with higher layer controllers. In addition, albeit not considered in this work, it might be assumed that, in real IoT applications, the probability of connection between neighbor edge devices is higher than between devices located at further distance, which would result in an additional benefit on the deployment of topologies with more layers.
Cloud providers Delay (ms) UPC hosts Delay (ms)
Amazon 45.246 Host 1 1.202
Google 9.959 Host 2 0.536
IBM 13.066 Host 3 1.250
Microsoft 13.143 Host 4 1.205