People's lives and habits will reach new breakthroughs thanks to the introduction of the Internet of Things (IoT). Being surrounded anytime and anywhere by billions of things communicating and sharing information with one another represents the latest step of the interaction between humans and technology.

Such a revolutionary paradigm involves very heterogeneous devices, from wearables, smartphones and computers associated to daily, personal activities, up to sensors and machinery systems employed for monitoring and control smart buildings, industry and cities [AGM+15]. In this direction, as each IoT device output is characterized by speci c structures and features, di erent kind of data are going to be simultaneously transmitted through the network. Some examples are represented by the small size spot measures typically produced by sensors for environmental monitoring, otherwise high quality and large size videos and pictures shared between computers. Moreover, data tra c is driven by the speci c application that it is related to, requiring appropriate quality of service. For instance, activities like video streaming need to be supported by high rates and low latency, while many others are oriented to energy saving, especially when battery power devices are involved. In general, taking into account all of these concerns is important in order to minimize the overall tra c load, but when dealing with the IoT it becomes essential as the presence of a large number of devices entails a signi cant growth of the amount of data volumes.

The e cient management of network resources is recognized to be very challenging, especially in cloudbased networks where the presence of a huge amount of devices simultaneously performing data synchronization may cause bandwidth saturation. Therefore, it follows that e ective protocols for remote data update are necessary to minimize the amount of data exchanged through the network and, consequently, to optimize the overall tra c load. Moreover, the reduction of information to be transmitted returns also to energy saving for all that IoT devices that are typically battery powered.

Unfortunately, data synchronization algorithms originally developed for computer systems badly t to the IoT since they are not able to handle heterogeneous tra c volumes and their performance do not consider device power consumption. An example is given by the rsync algorithm [TM96] representing the core of many, well known, cloud services like Dropbox. Given two parties each one storing di erent version of the same le (an old one and a newer one), the rsync algorithm performs a single round synchronization by recognizing the matching parts between the two le versions, so that the information to be exchanged is just that one necessary to make the old le version updated. In general, good performance are obtained when the size of les under processing is quite large, on the other hand, the algorithm su ers from ine ciency when dealing with small amount of data. So, rsync may not represent the best solution in the IoT case where few data are sporadically transmitted (for instance, sensors for environmental monitoring sending their spot measurements to the data center). Some other algorithms have been proposed in the literature with the aim to improve the performance of rsync, such as that one presented in [YIS08] where reconciliation techniques are applied to minimize the bandwidth consumption. Other solutions consider instead multiple round procedures in order to optimize the generated tra c amount like in [SNT04], but unfortunately undesired latency is introduced due to the bi-directional communications occurring between the two parties involved in the synchronization.

More recently, the problem of data update has been addressed with a view to IoT scenarios and applications. In this context, the heterogeneity and variability of IoT data are addressed in [ZL16] by proposing a remote synchronization based on timestamp and bitmap to improve the transmission e ciency. Furthermore, the work in [PCS+18] introduces an rsync-inspired algorithm where the knowledge of data characteristics are exploited to adaptively tune the synchronization parameters and optimize the amount of information to be transmitted.

Finally, the architecture itself characterizing the cloud services may represent a limit for the performance in the IoT context. Indeed, devices at the edge of the network may be very far from the datacenter node, so the process of remote data synchronization could su er from long latency, bandwidth ine ciency, bottlenecks and excessive device power consumption. A potential solution to all those issues is the edge computing [SCZ+16] that envisages the development of a de-centralized structure where many computing tasks are moved at the network edge, so closer to the IoT devices. The exploitation of this novel approach is described in [WZL+19] where a fog computing-based technique is proposed for data synchronization in the IoT.

Following this direction, on the basing of principles of edge computing, we investigate a cloud architecture where devices are connected to an IoT gateway, placed at the network edge, and performing remote les synchronization by interacting with the main data center. Speci cally, we consider a data synchronization mechanism given by the combination of Octodi with a rephrased version of the adaptive algorithm AC-rdi introduced in [PCS+18], in order to evaluate the bene ts of the presented solution on the network tra c load and on the reduction of the processing time requested by the synchronization procedure.

The paper is organized as follows. In Sec. 2 the network scenario is introduced, reporting the essentials of Octodi and AC-rdi . The architecture and features of the proposed le synchronization mechanism are detailed in Sec. 3. Sec. 4 reports some numerical results, and nally the conclusion is drawn in Sec. 5. 2

Let us refer to an IoT scenario where multiple devices (sensors, vehicles, machinery and so forth) periodically access the network to store their data and measurements on a cloud server. As previously mentioned, the potentially large number of entities simultaneously interacting with the cloud may create a bottleneck at the server node, so we consider a de-centralized architecture like that one described in Fig. 1 where many IoT gateways (IoT GWs) placed at the network edge are responsible for data collection and update. The proposed scenario is realized on the basis of the principles of edge computing, where data processing is performed near the devices, reducing latency and providing energy saving to battery powered IoT entities. Therefore, each IoT GW is supposed to have a storage capacity and computing power, so that data synchronization can be operated minimizing the interaction with the cloud central node (communications for network control and management may be considered anyway). Giving further details about the communication protocols involving IoT GWs and the central node goes behind the scope of this work, however we were inspired by a medical IoT application were medical devices communicate with short range links to a GW that on its turn is interconnected to the Internet. We focus the attention on remote data synchronization aspects. In this direction, we report below the essentials of Octodi and the adaptive algorithm in [PCS+18] that are combined to implement the synchronization mechanism. 2.1

Interestingly, the chunk size adaptation rule driving AC-rdi can be easily combined with any synchronization mechanism relying on the principles of rsync. In this direction, the study here proposed is on the integration of AC-rdi , conveniently modi ed, with Octodi tool.

First, it is worth highlighting that AC-rdi is performed on the current le update procedure, and returns an optimized parameter (the chunk size) to be applied in the next synchronization event. So, the processing performed at the IoT GW side considers two steps, that is the computation of les di erences by generating the le and then the chunk size optimization. A reference architecture describing this mechanism is essentially given by the cascade of the block for delta computing (named di computing ) and the block for chunk size optimization, as depicted in Fig. 3. The processing operated by the cloud, that is le compression and update, essentially is the same as in the original Octodi . Given the storage and processing capacity supposed for the IoT GW we assume that this node as able to store both FNEW and FOLD in its memory. So, the le can be computed internally, that is without the need to receive the old le version reference from the cloud. In this way, the downlink communication from the cloud to the IoT GW could be signi cantly reduced, saving therefore network trafc. The cloud would always deal with the le update operations, while data compression and transmission would only concern sporadic cases like for example failure events where the connection with the IoT GW needs to be restored. The computing requested by the IoT GW is instead summarized in the following steps. The synchronization starts when the IoT GW collects all the information related to FNEW and FOLD. The di erences between the two les are processed and the corresponding output le is generated. The adaptive chunking is then performed using the information (the tokens list) stored in , returning the new chunk size estimate dopt. Finally, both the le and dopt are sent to the cloud to let it perform its le version update. It is worth highlighting that the cloud must receive from the IoT GW the information about dopt so that it can correctly set up the parameters for the next synchronization procedure.

To implement the AC-rdi in the Octodi framework the algorithm has been rephrased in some parts, with the corresponding pseudocode being detailed below. Speci cally, the input is represented by the current chunk size and a vector gathering the token indexes, dold and Pt respectively. By computing the distance between consecutive token indexes (row 10) the distribution of matching chunks along the le is inferred and multiple partial estimates of the optimal chunk size are obtained (row 13-18). The new chunk dopt is returned by the average on the partial estiAlgorithm 1 AC-rdi Algorithm 1: Input: Pt Token index vector; dold current chunk size mates collected in Wm. The speed of adaptation of the new chunk size is ruled by two step sizes, namely

UP and DOWN. However, in order to avoid excessive variations of the output, dopt is allowed to range from half the old chunk size dold and 2 times dold. Furthermore, as described in the previous section, the chunk size driving Octodi can assume values from 128 to 31744 bytes, so the output of AC-rdi is anyway forced to meet this constraint even when the actually estimated dopt is out of the considered range. 4

The e ectiveness of remote synchronization algorithms strictly depends on the characteristics of data under processing and on the changes that they may be subject to. It is worth noting that the measurements produced by devices are typically gathered into les characterized by an header and a payload or, in more speci c cases, into structured formats like for instance JSON and XML. The knowledge of how the information to be transmitted is organized could be helpful in order to conveniently set up the synchronization mechanism, however the heterogeneity of data and devices in the IoT may not always allow the achievement of optimal performance.

In this direction, we have investigated the e ciency of the proposed adaptive chunking based Octodi , referred as A-Octodi in the rest of the paper, comparing its performance with those provided by the classical Octodi working with static parameters, referred as S-Octodi . Speci cally, by running the remote le synchronization on simulated data, we show how the exibility characterizing A-Octodi results to be useful for optimizing of the network tra c load, but also for reducing the processing time.

We preliminary considered the remote le synchronization as run on simulated les, the dimension of which has been initially chosen to be about 50 kB. Such a value is in line with the typical output generated by some IoT devices. Speci cally, the performance of A-Octodi and S-Octodi have been measured in terms of generated tra c percentage, given by:

T% =

dim( ) dim(FNEW ) 100 that is the ratio between the amount of data actually transmitted (the le ) and the dimension of the entire latest le version (the le FNEW). The results come from the average on 100 simulations (that is, 100 le synchronization procedures), considering di erent le update percentages expressing how much of the current le has changed with respect to its previous version.

The spatial distribution of updates within the le have been rst modeled as uniform and organized in blocks of variable size (from tens to hundreds of bytes). This kind of distribution represents the worst case for S-Octodi and, in general, for all the synchronization mechanisms working with static parameters since the updates essentially occur randomly in the le. The synchronization mechanisms have been implemented with di erent starting chunk sizes, but while these values remain static in S-Octodi , the adaptation provided by A-Octodi make them change as the simulations go on. S-Octodi considers by default the chunk size as equal to 2048 bytes. By looking at the results reported in Fig. 4 it is possible to appreciate how the use of such static value provides bad performance as the generated tra c percentage is in the order of 35%, increasing up to the 50% as the le update percentage grows (error bars referring to a 95% con dence interval are highlighted for all the measurements). The reason is that the chunk size is too large with respect to the le size, therefore it is very hard to recognize matching blocks of bytes. On the other hand, with A-Octodi , by adapting the chunk size to an optimal value, the amount of generated tra c results to be signi cantly 1 3

File u5pdate percenta1g0e (%) 15 20 reduced down to the 15%-25%. The same simulations have been run considering a starting chunk size equal to 512 bytes that has resulted to be more suited to the considered scenario, in fact S-Octodi returns an average tra c percentage ranging from 13% to 30%. However, the adaptive mechanism driving A-Octodi allows the achievement of even better performance, as the generated tra c percentage is reduced by the 6%7% with respect to S-Octodi . Finally, the remote le synchronization has been performed using the minimum chunk size allowed by Octodi , that is 128 bytes. In this case A-Octodi provides essentially the same performance of A-Octodi using a starting chunk size equal to 512 bytes. This fact can be explained by looking at Fig. 5 describing the adaption of the chunk size as the simulations proceed (the values on the vertical axis are reported on a logarithmic scale for convenience). Speci cally, it is possible to observe that when the initial chunk size is 512 bytes the value tends to decrease (the same happens for the chunk size initially equal to 2048 bytes), while if the starting chunk size is 128 byte, the adaptation mechanism returns increasing values. Therefore, as the chunk sizes tend to converge, it is reasonable to measure the same performance. Furthermore, we observe that, since the optimal chunk size value equal to 150 bytes is quite close to the minimum one allowed, S-Octodi and A-Octodi return the same average tra c percentage when a 128 )s1024 e t y b (ze 512 i s k n huC256 128 bytes initial chunk size is considered.

Finally, it is worth noting that when the di erences between two les are computed returning the list of matching blocks, the Octodi tool is able to compress the corresponding tokens in a single interval if they are listed in ascending order, reducing the information to be sent. So, using a small chunk size may seem always convenient since by doing so, even if the number of generated tokens is higher than the case when a larger chunk size is used, they can be however compressed . So this is the reason why Octodi and A-Octodi return the same generated tra c percentage. However, in general the time for le processing and di erence grows increases as the chunk size decreases.

The bene ts coming from the use of an adaptive approach with respect to the static one have been also evaluated by comparing the time required for processing. Of course the performance depend on the speci c hardware employed to run the synchronization procedure, so we have introduced the following metric: RTp =

Tp,adaptive

Tp,static (1) that is the ratio between the average processing time referring to the adaptive mechanism and the average processing time for the static one. By doing so, the performance comparison between adaptive and static mechanism can be expressed independently from the hardware used for tests. In this direction, Tab. 1 reports the results of RTp measured combining the AOctodi and S-Octodi implementations. Speci cally, having values less than 1 means that the adaptive mechanism is less time consuming than the static one. On the other hand, when values exceed 1, A-Octodi requests more time than S-Octodi . However, this latter results is not always negative. In fact, for example, even though A-Octodi 512 is slower than S-Octodi 512, the use of the adaptive approach provide a signi cant tra c saving with respect to the static mechanism (Fig. 4). Moreover it is also shown that, in general, the use of a small chunk size leads to the recognition of a larger number of matching blocks, but it makes the di erence computing processing longer.

In order to highlight the performance of the considered synchronization mechanisms and the importance of using a proper chunk size, we have performed other simulations considering smaller les, with size equal to 5 kB. By referring to Fig. 6 we observe how using 1 3 15

20

50 60 no. Simulations 10 20 30 70 80 a 2048 bytes chunk size results to be unsuitable, with very low performance provided by S-Octodi . Signi cant improvements are instead obtained when considering A-Octodi . Actually, the chunk size equal to 512 bytes is recognized to be too large as well, in fact tra c percentage generated by S-Octodi is quite high, around the 70%. In fact, the curves in Fig. 7 show how the optimal chunk size is essentially the minimum one allowed by Octodi . So, when dealing with very small size data it is convenient to reduce the chunk size, as demonstrated by the results referring to S-Octodi and A-Octodi implemented with an initial chunk size equal to 128 bytes. Moreover, the advantage given by an adaptive approach can be once more appreciated by observing that the performance of A-Octodi implemented with a 512 bytes initial chunk size approaches the one provided using a smaller chunk size. Interestingly, by referring Fig. 7, the adaptive chunking seems not have e ects when A-Octodi is implemented according to a 128 bytes initial chunk size, since no changes are observed. At rst glance, it would be inferred that the optimal chunk size is exactly 128 bytes. However, taking into account the constraint about the minimum chunk size characterizing Octodi , the optimal chunk size could be actually less than 128 bytes as well. So, in order to investigate this issue, we simulated the behavior of Octodi in Matlab removing the limit about the allowed chunk size, and we found out that the optimal value would be around 70 bytes, as demonstrated by the dashed curves reported in Fig. 7. Finally, Tab. 2 reports results referring to the time processing ratio between adaptive and static mechanisms, and it is possible to appreciate that the processing time of A-Octodi is always less or at most equal to the processing time characterizing A-Octodi . So, in this context, we can conclude that when the dimension of les is in the order of few kilobytes, the use of Octodi tool may not be convenient for data synchronization since the constraint about the minimum value of the chunk size could not allow the achievement of best performance in terms of tra c saving.

The second scenario under investigation has considered the le synchronization performed on input les where the updates distribution was modeled according to the following exponential probability density function: f (x; ) = x3e x 0 < x 1 with = 0:1 and the random variable x, representing the index (position) of new bytes in the original le, normalized to 1 (Fig. 8). By doing so, we refer to the possibility of having updates occurring at the end of the le more frequently than at the beginning, because the more x is close to 1 the more the updates are located in the nal part of the le. Figs. 9-10 reports the results referring to the remote synchronization of 50 kB and 5 kB les, respectively. In general, we observe the better results with respect to Figs. 4-6 since now the updates are no more randomly distributed, but concentrated at the end of the le. So it is reasonable to nd a higher number of matching blocks, resulting in a lower generated tra c amount. However, the 0 1 3 comparison between S-Octodi and A-Octodi implemented with di erent chunk sizes highlights the same trend, thus showing the e ectiveness of the proposed adaptive approach even in this scenario. For the sake of completeness, we also report in Figs. 11-12 the performance of A-Octodi in terms of chunk size adaptation for both le size cases. The chunk size converges towards quite the same value reached in Figs. 5-7, approximately around 70 bytes. Tabs. 3-4 report the results in terms of time processing ratio referring to the 50 kB and 5 kB les synchronization analysis, respectively. In that case we observe that the processing time referring to A-Octodi is in general higher than the processing time characterizing S-Octodi . 128 40

50 60 no. Simulations 10 20 30 70 80

However better performance are provided in terms of generated tra c percentage, as shown in Figs. 9-11.

Finally, we considered data synchronization involving le of variable size. Speci cally, we run the synchronization mechanism on 100 les with sizes ranging from 40 kB to 80 kB. Each le is modi ed with respect to its previous version according to an update percentage randomly varying between 5% and 20%. The updates are represented by bytes addition, removal and substitution. The generated tra c percentage and the processing time ratio, averaged on 100 simulations, are reported in Tab. 5 as a function of the synchronization mechanism employed, that is static or adaptive, and of the chunk size. It is worth highlighting that the values referring to A-Octodi are quite uniform, thus meaning that the use of the adaptive approach makes the performance less sensitive to the choice of the initial chunk size. On the other hand, when using a static mechanism, the set up of xed, unsuitable chunk size may lead the generated tra c percentage to be higher, as in the case of S-Octodi 2048. The e ectiveness of A-Octodi can be further appreciated by observing Fig. 13 reporting the chunk size adaptation along the 100 simulations. In fact, despite A-Octodi is initialized with di erent values, the chunk size tends to adapt toward the same optimal value around 200 bytes. A-Octodi 128 S-Octodi 128 A-Octodi 512 S-Octodi 512 A-Octodi 2048 S-Octodi 2048

Summarizing, the implementation of the adaptive chunking in the Octodi framework has allowed the realization of a remote synchronization mechanism characterized by low sensitivity to the characteristics of the les under processing. This aspect turns out to be signi cant in the IoT context where heterogeneous data are typically handled. 5

This paper proposed an analysis of remote data update solutions to be used in IoT scenario. Speci cally, one of the most known le synchronization tools, namely Octodi , has been combined with a recently proposed algorithm for adaptive chunking. The performance of the resulting mechanism has been evaluated, highlighting the provided tra c saving with respect to the classic Octodi version working with a static approach. The proposed solution aims at catching the bene ts of an edge computing for IoT that helps to reduce the network load on the one side and the IoT power consumption on the other side.