Page 49 - Kaleidoscope Academic Conference Proceedings 2021

of I/O virtualization. In particular, the direction of the Idle 10 requests
arrows corresponds either to an input (a sensor) or output CPU RAM CPU RAM
(an actuators). Reverse proxy ' 0% 1.1% 3.4% 1.1%
WS tunnel client ' 0% 4.1% 4.2% 4.1%
6. EXPERIMENTAL RESULTS Zun agent ' 0% 9.7% 0% 9.7%
Lightning-Rod ' 0% 0.8% 0% 0.8%
In the following section, a preliminary evaluation of the Total ' 0% 15.7% 7.6% 15.7%
deviceless system is provided. In particular, we focus on
the resource usage of the system on IoT nodes and the impact Table 1 – The resources usage of the deviceless system on an
of the new Zun networking driver we introduced. For that IoT node
purpose, we deployed the cloud side of the system (i.e.,
Serverless Deviceless Deviceless
IoTronic, Qinling, Zun) on a 10th gen i5 Intel-based late 2020 (Cloud-based) (50 ms latency ) (100 ms latency)
Macbook Pro. We mimic the IoT node using a VM hosted on Execution 150 ms 419 ms 850 ms
the same machine to have a fixed latency emulating a Wide time
Area Network (WAN) interconnection. Therefore, we can
evaluate the impact of the networking driver we conceived. Table 2 – Execution time comparison between serverless and
In particular, we used the Linux Traffic Control (TC) with deviceless
queuing disciplines (qdisc) to set the latency between the
the request on the cloud as well as the delays to reach the
cloud and the IoT node. The IoT node (i.e., VM) is configured
containers (either on the cloud for serverless or the network
with one vCPU and 1GB of RAM.
edge for deviceless), execute the function and send back the
result. Of course, when talking about deviceless, we are
In Table 1 we report the averaged CPU and RAM usage of
expecting higher delays due to network latency. This is what
the deviceless system on the IoT node. In particular, we
we can see from Table 2. Executing a function on the cloud
report the resource usage of all the processes involved on
requires only 150 ms. On the other hand, when the containers
the node side (i.e., WebSocket tunnel client, Zun compute
are on the network edge, more delays are introduced. We
agent, Lightning-Rod, and the reverse proxy). We are
would like to mention that the delay added is not equal to the
considering two scenarios, an idle mode, when all the
Round Trip Time (RTT): sending the request and receiving
processes mentioned earlier are running but not executing
the result. In fact, if it were the case, we would expect a
any task (during 10 minutes). The second scenario, instead,
value around 250 ms when the latency introduced by the
is when the IoT node receives ten simultaneous functions’
network is equal to 50 ms (i.e., serverless execution time +
execution requests (the table reports the results averaged over
RTT = 150 ms + 100 ms). However, since the new driver we
20 runs).
are introducing uses a TCP-based Websocket tunnel, which
means a three-way TCP handshake (i.e., 1.5 RTT) plus the
As we can notice from the table, when the IoT node is not
time required to send the execution request and receiving the
receiving any execution request, the deviceless system does
result through the tunnel (i.e., 1 RTT), the delay increases
not use any CPU resources. Regarding the RAM usage,
accordingly (see Table 2).
the system uses precisely 15.7% of the 1 GB of memory
available. We mention that the RAM values for all the
processes remained constant and equal to the values shown in 7. CONCLUSION AND FUTURE WORKS
the table during the 10 minutes. When the IoT node receives
ten simultaneous execution requests, the CPU usage increase This paper introduced our system for extending the serverless
for both the LR reverse proxy (that routes the requests to the paradigm to the network edge down to IoT devices.
runtime) and the WS tunnel client (a WS tunnel is established Specifically, the approach uses the serverless paradigm to
between the cloud and the IoT node). Yet, both the Zun agent interact with IoT resources such as sensors and actuators. As
and LR do not impact the CPU usage as they are not involved discussed, the proposed new approach, deviceless, exempts
during functions’ execution (they are part of the control plane: the IoT developers from managing the IoT infrastructure.
creating runtimes and instantiating WS tunnels). As future works related to the approach, we would like to
improve the performances in terms of the delay required
To further evaluate the solution, we conducted another to execute the functions. In particular, a solution that can
experiment to assess the impact of the network latency on be considered to decrease functions’ execution latency is
the functions’ execution time. We specifically compared the instantiating WebSocket tunnels more proactively. Thus,
execution time between a standard cloud-based serverless anticipating demand for function execution requests with
deployment and the deviceless approach that uses the new predictive routines and keeping TCP sessions alive to
WebSocket-based Zun networking driver. Table 2 reports the avoid three-way handshakes for most functions’ invocations.
results obtained when comparing serverless and deviceless Besides, to overcome the cloud issues related to latency
execution times (results averaged over 10 runs are reported). and enhance the deviceless approach performances, another
In the table, the execution time refers to the whole process aspect to investigate is exploiting the proximity of the ETSI
starting from sending the function’s execution request until MEC distributed environment to orchestrate the serverless
getting the result. This process includes the management of functions’ at the edge [23]. Thus, a nearby MEC entity can

– xlv –