Page 126 - ITU Kaleidoscope 2016

various types of attributes. However, they are not designed located in the surrounding networks (at 3-4 hops distance)
to minimize the response time. and measured the average value of name resolution
latencies of each server by sending 250 queries from a
We aim at meeting mainly the following two performance Google Chrome resolver program. We found that the lowest
requirements of the IoT directory service: (1) being capable value was of 35 ms from the fastest server, while the
of storing a huge number of records (about 1 billion highest value was around 280 ms from the slowest server.
records), and (2) being capable to provide fast resolution of These values also include the propagation latency, and we
names into related attributes (latency of few milliseconds). can infer that the DNS servers are not currently placed
We require to keep the lookup latency as low as possible optimally.
because, accordingly to the ITU Report on Tactile Internet
[9], the IoT applications involving human senses (e.g. sight, From the above observation, it is clear that the network
audio, or touch) require the system response within the latency significantly dominates the DNS lookup latency.
order of magnitude of 1 ms to 1 s. Our initial target is 10 ms Since the DNS BIND database implementation has small
to enable those applications achieve their response times query latency, we may leverage it for storing IoT records
without confronting the latency added by current name (of course, with some modification to store heterogeneous
resolution systems. names and expedite update process) or other NoSQL
databases. However, to reduce the network latency and
This research has two parts: (1) architectural design of maintain high performance despite fluctuation in workload
and network conditions, we need to apply new design
record storage, replication, lookup, and update functions, approaches as listed below.
and (2) dynamic allocation of computational and network
resources to the directory service so that the performance
requirements are always met despite fluctuation in the (1) IoT service-wise directory services: To meet the
distinct performance requirements of various services,
workload. However, because of space limitation, this paper
presents only the first part, i.e. the architectural design, and we consider that each IoT application will have its
own directory service. For example, automated/safe
gives only a very brief outline of the resource allocation driving and smart-grid control applications will have
procedure. two different directory services.
(2) On-demand, trackable record caches: To achieve
The remainder of the paper is organized as follows. Section low latency lookup by reducing the communication
2 reviews the DNS performance as a related technology and distance between a client (i.e. querying node) and the
provides a list of the design approaches used in the directory server, caches are created and maintained
proposed IoT directory service. Section 3 presents the on-demand in replica servers located closer to the
architecture detail. Section 4 describes the record client. The caches are trackable by the authorized
replication, lookup, update, and resource allocation directory so that any update of dynamic records in the
procedures. Section 5 concludes the paper by outlining the authorized database can be reflected in all cache
future work items. replicas instantly by a fast update process.
(3) Dynamic resource provisioning: To meet the IoT
2. ANALYSIS OF RELATED WORK AND DESIGN directory service performance requirements despite
APPROACHES fluctuation in the workload and network conditions,
the appropriate amount of computational and network
In this section, we first present a review of DNS lookup resources allocated to the replica servers is adjusted
performance by carrying out a simple experiment as related dynamically. Thus, we consider managed networks
work, and then list up the approaches we have used in the that have the capability to provision the resources
design of the proposed IoT directory service. dynamically.
(4) Leveraging established component technologies: To
We stored 10,000 records in BIND 9 software in a computer improve its deployability qualities, our approach relies
on established tools for database management,
and measured the lookup latencies by sending queries at software-defined networking (SDN), network function
various rates by using DNSPerf from the same computer. virtualization (NFV), and virtual machine (VM) to
The average lookup latencies were 0.10 ms, 0.15 ms and 2 allocate and adjust resources for storage, computation,
ms, respectively, for 1,000 queries/s, 10,000 queries/s and and communication. Although the VM setup and
100,000 queries/s. We also measured the update latency by usage may incur additional latency, VM provides an
using nsupdate command, which was on average 6 ms. easier and effective tool for segmentation, assignment,
These lookup and update latencies do not include any control and configuration of resources. We expect that
network latency as both the resolver and server were this approach would be helpful for standardization and
residing in the same computer. To assess the impact of incremental deployment of IoT application services in
network latencies on the lookup latencies, we ran a simple collaboration with business partners such as
experiment using Google namebench tool from a computer equipment vendors and network service providers.
connected to our lab network. We scanned 11 DNS servers

– 108 –