Konstantinos Trichias
email: kostas.trichias@tno.nl

Lucia D ' Acunto
email: lucia.dacunto@tno.nl

Floris Drijver
email: floris.drijver@tno.nl

Bastiaan Wissingh
email: bastiaan.wissingh@tno.nl

Ranged Name Retrieval: Design and Evaluation of a Flexible Data Retrieval Approach for ICN

In Information-Centric Networking (ICN), applications request data based on the (exact) name of the data of interest. This poses a challenge for a growing number of applications, which do not know a priori the full name of a data object they seek, or do not necessarily need a specific data object, but are interested in a certain scope (e.g. the temperature in a particular geographical area). To address this challenge, we propose the more flexible and application-agnostic Ranged-Name Retrieval (RNR), which allows applications to define a range within each hierarchical component of the name they are requesting, obtaining in return one of the objects within that defined range. The performance evaluation of RNR indicates that, compared to the state of the art, it improves the bandwidth utilization efficiency 16-fold when retrieving data with unknown names, and even decreases the average end-to-end (E2E) delay for data delivery, while only adding 2% overhead for the processing of ranged-names.

Introduction

Information-Centric Networking (ICN) aims at evolving the Internet infrastructure from a connection-oriented towards a data-oriented approach, by directly addressing data objects themselves. The name of a data object is arguably a central concept in ICN. Popular ICN architectures, such as CCN [START_REF] Jacobson | Networking named content[END_REF] and NDN [START_REF] Zhang | Named data networking[END_REF], have hierarchically designed names. The fact that any data object can be described by a hierarchical name has many benefits, from the ability to cache the data at intermediate nodes, to security and efficient routing and forwarding [START_REF] Zhang | Named data networking[END_REF]. However, using the same hierarchical naming mechanism to also retrieve these data objects presents some limitations, primary among which is the fact that an application is required to know the exact name of the object it wants to obtain. In order to mitigate this issue, CCN supports the concept of "manifests", while NDN supports matching of Interests to Data packets with "partially known names", but both techniques suffer from limited flexibility and scalability, and can be unpractical for a number of emerging applications, where the space of potential named objects is very large and/or where a (ultra) low latency response is required. One example is that of an Internet-of-Things (IoT) application interested in sensor data related to a particular geographical area, e.g. a temperature sensor between certain longitude/latitude boundaries. In this case, the application is not interested in the readings of a specific sensor within that area, and the space of potential data objects may possibly be much larger than the actual data objects available.

Easing the process of applications obtaining the data they need, through a potentially vast (and/or partially unknown) naming space within acceptable latency, becomes crucial for the success of ICN as future Internet architecture. We aim to address this challenge by increasing the flexibility of data retrieval for hierarchical names. In particular, we introduce a Ranged-Name Retrieval (RNR) approach, which allows applications to define a range within each hierarchical component of the name they are requesting, and obtain in return one of the objects within that defined range. An early version of RNR was demonstrated at the ACM ICN 2016 conference for a surveillance use case [START_REF] Wissingh | Extending named-data-networking with support for names with range indications[END_REF], as a proof of concept. In this paper, we expand on our previous work, and evaluate RNR's performance against legacy NDN operation via extensive large scale simulations in NS-3, as well as via small scale experiments with real nodes running a version of NDN with the RNR extension. Our experiments show that a 16-fold bandwidth utilization improvement and a decrease of the end-to-end (E2E) delay can be achieved with RNR, while only imposing a 2% increase in the computational load for realistic scenarios.

Related Work

The need for data retrieval mechanisms better suited to the requirements of applications has been tackled in previous work in ICN. In particular, some of the advantages of using a range in the name of the Interest to retrieve data object(s) in ICN has been advocated by both industry and academia proposals. At a first instance, the authors in [START_REF] Wang | Data naming in vehicle-to-vehicle communications[END_REF] propose the use of ranges in Interest names for a vehicular network application, as a way for vehicles to request information about an area around specific geographical coordinates and/or between certain streets, and within certain time periods. While this is a first attempt at defining efficient name ranges, the proposed scheme is limited by its application-specific nature (i.e. ranges can only be interpreted by the nodes running the specific vehicular networking application) and by the assumption of a known name-space (known street names). Another application-specific proposal, [START_REF] Co | Terminal device based on content name, and method for routing based on content name[END_REF], describes a method for efficiently requesting content that is segmented (e.g. a video file comprised by multiple temporal "chunks") in ICN, by means of so-called "block queries". Block queries are inserted in the header of the Interest packet and the ICN routers interpret a range as being the last part of the name, hence limiting the applicability of this solution to names with only one range and always positioned at the end of the name.

The work in [START_REF] Varvello | Range queries in manet: Can information-centric networking help?[END_REF] also addresses the issue of obtaining all the data within certain segment ranges, with multiple components of the name possibly carrying the range. To enable their solution, the authors of [START_REF] Varvello | Range queries in manet: Can information-centric networking help?[END_REF] introduce the concept of "pointers", network nodes associated to specific name components which keep track of where all content within those specific names resides. However, the knowledge base of "pointers" needs to continuously be updated (which is difficult in highly dynamic scenarios), and pointers become single points of failure, decreasing the network's robustness.

What most of these solutions seem to have in common is that a) they propose application-specific naming schemes (only ICN nodes equipped with specific applications are able to understand / process the proposed naming scheme) and/or b) assume the existence of a finite and well defined space of named objects for which the request will be made. Our solution builds on top of the generic lines proposed in the literature and we expand the functionality of such a rangedname retrieval mechanism to operate in an application-agnostic manner and to account for vast (unknown) name spaces, while still relying on the distributed routing mechanisms of ICN architectures.

RNR: the Concept

Use Cases

In the era of Big Data and Internet of Things, an exploding number of devices is producing and requesting data and in a plurality of scenarios the exact name of an object is not known in advance: either because of the mobility of data producers in the network, or because of the dynamicity of certain applications (e.g. content on-demand, or within specific time frames), or simply because the exact number, type and name of all nodes (IoT devices, sensors, vehicles, etc.) deployed within a certain area, is not always known. In many of these cases, though, applications may know an approximation or part of the name, and seek to retrieve a data object within one request -either because of latency requirements, or because the specific data object to be retrieved is not important, as long as it fits within a certain "scope". The design of RNR stems from these needs. A few use cases where RNR is beneficial are outlined below.

IoT/monitoring: Data is typically produced by (static) sensors placed in the area of interest (e.g. urban/environmental monitoring, use during festivals). In such cases, the name space of possible data objects may greatly exceed the number of actual data objects and many applications may not even be interested in the output of a specific sensor, as long as they obtain one sensor reading within a certain range. Ranges may appear in several components of the name (e.g. one indicating latitude and the other longitude), see for example Figure 1 (left).

Vehicle-to-Everything (V2X): In this use case the sensors themselves are mobile (on the vehicles), and the data they produce may change name over time. For example, an application that may want to sample the speed of a random vehicle between street numbers 100 and 160 of the Kalverstraat in Amsterdam (Figure 1, left), may receive a response by any vehicle situated in the area, and at different times that information may be provided by different vehicles fitting the criteria of the request.

Immersive media (VR/AR): In Virtual or Augmented Reality (VR / AR) applications, content is commonly spatially segmented, with each spatial segment catering for a different, wide, viewport [START_REF] Corbillon | Viewport-adaptive navigable 360-degree video delivery[END_REF][START_REF] D'acunto | Using mpeg dash srd for zoomable and navigable video[END_REF] (Figure 1, right). Viewports for immersive media are usually centered a few degrees apart (e.g., with steps of 30-60 degrees [START_REF] Corbillon | Viewport-adaptive navigable 360-degree video delivery[END_REF][START_REF]Next Generation Video Encoding Techniques for 360 Video and VR[END_REF]), and are often partially overlapping [START_REF] Niamut | Immersive live event experiences-interactive uhdtv on mobile devices[END_REF]. As users move their head in the virtual world, the content matching their new orientation needs to be streamed to them. This adaptation needs to be very quick because of the extremely low latency requirements of immersive media use cases. If an application does not know the viewport segmentation used by the video source (e.g. when the content is produced live), it might be convenient for the application to specify a range of viewports that will cover the user's orientation (e.g. 30 • clockwise from the north, within a 30 • range: /WaltDisney/JungleBook/orientation/[15:45] ) and let the network fetch the closest viewport matching this orientation, in order to minimize latency.

A More Flexible data Retrieval Approach

To cater for the different needs and use cases as described in the previous section, we have designed and built Ranged-Name Retrieval (RNR) as an extension to NDN. Embedding RNR at the network layer (i.e. extending the core of NDN) also makes our approach application-agnostic, since nodes on the request path can process ranged-names without needing to invoke (and have installed) a specific application to deal with it. Our approach remains compliant to the "1 Interest packet, 1 Data packet" principle: even if an Interest with a ranged-name may be potentially satisfied by multiple data objects, only one will be returned to the requester. RNR comes with two inherent advantages. On one hand, it facilitates the retrieval of data with unknown names by applications, while on the other hand its application-agnostic design also has the potential of decreasing the network traffic, since it may be used by all applications, independently of their nature, and since ICN nodes in the network understand the range and will be able to fetch the closest data matching the range. Even in cases where the application knows the exact name of a data packet, the use of an Interest with a range may result in reduced end-to-end latency for data delivery and traffic per link, since a data object that also satisfies the application and is different than the originally intended one, may be fetched by an ICN node in closer vicinity.

Implementation and Experimental Design

RNR extensions to NDN

The extensions for supporting the RNR concept, implemented on NDN version 0.4.1, are described below.

A New Name Component in Interest Names: We have introduced a new type of Name Component, a Name-Range Component (NRC) [START_REF] Wissingh | Extending named-data-networking with support for names with range indications[END_REF], that includes special syntax to indicate ranges within Interest packets. The NRC is implemented as a new Type-Length-Value (TLV) type, so that NDN routers can easily distinguish them from regular name components. Only names in Interest packets are allowed to have a NRC in them.

Processing incoming Interests: The NDN network forwarder has been extended to be able to process incoming Interests bearing NRCs name components. When a NDN node receives a new Interest, it adds it to the Pending Interest Table (PIT) and checks whether this Interest is already pending. Upon insertion in the PIT, if the Interest contains a NRC, it is flagged and its position in the PIT is saved in an additional "NRC index table" for quicker lookups on the incoming data path. If the Interest is not pending, the node performs a lookup in the Content Store (CS). When the prefix of the Interest contains a NRC, the node searches the CS for possible entries within the range of the prefix. If a match is found, the matching entry is returned, and the corresponding PIT entry is removed. If no match is found, the node looks in the Forwarding Interest Base (FIB) for possible entries within the range of the prefix. If a matching entry within range is found, it is returned and used to forward the Interest containing the NRC.

Processing incoming Data packets: The NDN network forwarder has also been extended in order to match incoming Data packets with PIT entries containing NRCs name components. Specifically, upon receiving an incoming Data packet, a RNR node checks the PIT for entries that match the Name of the Data packet. When searching the PIT, the node first checks for standard entries, and then proceeds to check for NRC entries, using the NRC index table.

Simulator Integration and Evaluation Scenarios

The network level performance of RNR is evaluated using version 2.3 of the ndnSIM module [START_REF] Mastorakis | ndnsim 2: An updated ndn simulator for ns-3[END_REF], available for the NS-3 simulator. For all nodes in NS-3 simulations (whether a consumer or a producer) caching was disabled for reasons of simplicity. In fact, for this initial evaluation, our goal is to provide a good understanding of how RNR helps with fetching content with unknown name components from the original, spatially distributed producers themselves. The introduction of caching, which is part of our future work, is not expected to alter the outcome significantly, since any node that would cache a data object could also be seen as a new producer of that same data object. The consumer nodes transmit NRC Interests following a realistic Zipf-Mandelbrot distribution.

Network level evaluation To get a full picture of RNR's capabilities, we evaluated its performance in a large scale network, and performed a sensitivity study of the various network parameters that can affect its performance. For this purpose, we have used the NS-3 simulator with the ndnSIM extension and the RNR upgrades.

The performance of RNR under varying network conditions is bench marked against baseline scenarios where legacy NDN is used, applying three major Key Performance Indicators (KPIs):

-average end-to-end delay (E2E delay), i.e. from the generation of the first Interest to the delivery of the corresponding Data packet; -bandwidth utilization, i.e. traffic on the wire in MB (differentiating between Interest and Data traffic); -Interest success ratio i.e. percentage of Interests that returned a Data packet.

Since there is no official approach in NDN on requesting data with unknown names, an assumption has been made regarding the functionality of the baseline scenarios using legacy NDN. A traditional approach would be having the consumer sending out sequential legacy NDN Interests for the names in the specific range under consideration, until a name is used that corresponds to actual existing data in the network, at which case the correct data object will be returned. As an example, in the case of a temperature reading from an unknown street number in Amsterdam in the range [20:40], the RNR scenario would use an Interest with a name such as /NL/Amsterdam/Kalverstraat/streetnr/[20:40]/temperature, while a baseline scenario would start transmitting sequential Interests with names such as /NL/Amsterdam/Kalverstraat/streetnr/20/temperature, /NL/Amsterdam/Kalverstraat/streetnr/21/temperature,..., etc. until it transmitted an Interest with an existing name, and the corresponding Data packet is returned. Since transmitting these Interests in a sequential fashion, and waiting for a timeout of the previous one before sending the next one, would result in unrealistic delays that no application could tolerate, we have designed the legacy NDN baseline operation to flood all individual Interests at the same time, thus keeping delays at a reasonable level. In the aforementioned example, that would mean that in the legacy NDN case the consumer would flood the network with 21 Interests at the same time, and hope that at least one of them finds a match and returns a Data packet. The Traffic Mix (% ranged requests) parameter (Table 1) indicates the percentage of requests where a range is used, which are implemented by means of one NRC interest for the case of the RNR implementation, and by means of the flooding approach for the case of the legacy NDN implementation. The Range Size parameter indicates, for the legacy NDN implementation, the amount of parallel Interests that are flooded in the network.

For both the legacy and RNR versions of NDN, the "best route" forwarding strategy is employed. Furthermore, a Zipf distribution is used for content generation and a realistic Barabási-Albert topology is used for the network layout, with a varying number of nodes to cover the entire range from small-scale to large-scale NDN networks, while the simulation duration was network-size dependent with a minimum requirement for 10 5 transmitted Interests per scenario. All nodes in the network were either a consumer generating Interests or a producer generating data (content randomly distributed over the available producers), while at the same time all of them could act as forwarders. Different combinations of consumer / producer ratios were evaluated as can be seen in Table 1. Finally, different Data Packet Sizes were implemented in order to cater for applications with different needs, with a maximum packet size of 1.5 KB to simulate the maximum MAC PDU size over Ethernet. The Data Availability parameter indicates the actual percentage of existing data objects in relevance to the possible name space for a name component. As can be understood, Data Availability is far less than 100% in most scenarios, resulting in a lot of failed (timed-out) Interests in both legacy and RNR implementations of NDN, when looking for data with unknown names. For both implementations a "penalty" of 1 second (equal to the timeout timer) was imposed to the E2E delay for every failed Interest.

For the purposes of this evaluation, we use the "immersive media" use case described in section 3 where the video content is spatially segmented into specific viewport orientations. For simplicity, we assume that the content only offers a horizontal degree of freedom (i.e. users can look around 360 • , but cannot look up or down). In this case, the possible name space for the component "orientation" is [0-359], corresponding to degrees starting from the North. In an exemplary case where the entire 360 • video would be covered by 24 viewports, equally spaced (each 15 • apart), the Data Availability for such a case would be 24/360 = 6.6%. An overview of all the settings is presented in Table 1.

Performance Evaluation

In this section, we present the outcome of the large-scale NS-3 simulations and elaborate on the gained insights. During the evaluation while the effect of one parameter on the performance of RNR was under investigation, some default values have been selected for the rest of the parameters in Table 1, for the experiments on the simulator. The selected default values per parameter represent a realistic scenario and are indicated with bold and underlined text in Table 1.

Network wide evaluation

We have evaluated the network-wide performance of RNR NDN based on our NS-3 implementation (see Section 4.2), using the parameter values from Table 1. In both cases there is an upper limit of the E2E delay at 1 second (1000 ms) which is caused by the high "miss" ratio of Interests and the resulting enforcement of the time-out penalty (as described in Section 4.2). When Data Availability is very small (Figure 2 From Figure 2 (a) we can observe that the average E2E delay drops significantly for higher Data Availability values (down to about 11 ms for 100% Data Availability). In these cases most Interests return a Data packet and there are almost no time-out penalties enforced, depicting the pure latency of the network. The fact that legacy NDN and RNR NDN (using the default values for RNR settings) seem to provide similar delays is attributed to the implementation of flooding for the legacy NDN as a way to request data with unknown names (see Section 4.2). Since legacy NDN 'floods' the network with multiple Interests at the same time, it is able to attain a similar latency as RNR NDN does by using one Interest to achieve the same 'search'. This results in a significant difference in used bandwidth, as depicted in Figure 3.

From Figure 2 (b) we can conclude that RNR NDN is a much more efficient way of looking for data with unknown names, since the more ranged requests are used, the lower the average E2E delay. The entire range of traffic mix for the legacy NDN is dominated by the 1 second penalty (due to the default 10% Data Availability), since with higher traffic mix, more Interests are 'flooded' into the network and even though more Data packets are returned, the ratio of successful-to-failed Interests remains very low. This is not the case for the RNR NDN implementation which can achieve a search over the same range of names with only one Interest. As a result when the Traffic Mix is close to 100% (all Interests are ranged requests) most Interests are successful and there are very few time-out penalties imposed which greatly improves the performance. In a realistic scenario we expect the Traffic Mix to match the percentage of data requests with unknown names, i.e. if 10% of the requested data have unknown names then approximately 10% of NRC Interests should be used. Next to the average E2E delay, we have looked at the bandwidth used, in terms of MB on the wire, to achieve the same result (i.e. obtain a data object in the range) for both legacy and RNR NDN. This KPI enables us to evaluate the overall efficiency of the two solutions.

Figure 3 (a) depicts the bandwidth utilization per solution versus the Traffic Mix. This figure provides many interesting insights, foremost of which is that the bulk of the traffic in the legacy NDN case originates from the Interests while in the RNR NDN case it originates from the Data packets returned. Although the Data packets are much larger in size (default value of 1KB) compared to the 58 Bytes of the Interest packets, in the case of legacy NDN the Interest traffic dominates the bandwidth utilization, as a result of the fact that a large number of Interest packets is transmitted while only a low number of Data packets is returned. The RNR NDN on the other hand uses a fixed amount of bandwidth for Interest traffic, while the more ranged requests that are used the better the success ratio (transmitted Interests vs Delivered Data packets) and hence more data is delivered. It is also interesting to note that the legacy NDN Interest traffic load increases with increasing range utilization since more and more Interests need to be flooded, while at the same time the increase in returned Data packets is minimal (from about 10 MB for 0% ranged requests to about 12 MB for 100% ranged requests) and remains even under the RNR NDN Interest traffic. During our experiments we also observed that for 100% ranged requests the success ratio is also 100% which serves as a good sanity check for the scenario under consideration. With the default values used here (Data Availability = 10%, NRC range = 25, name space = [0-359]) it is expected that there are about 360*10% = 36 individual data objects (VR viewports). With an approximate equal spacing among them it is expected that each viewport will be about 360 / 36 = 10 • apart. Since the range used has a size of 25 • , it is then expected that when 100% of the Interests are ranged requests there will be at least one (likely two) data object within this 25 • range that satisfies each Interest and hence all Interests are successful, bringing the success ratio to 100%. The above presented analysis indicates that RNR clearly outperforms legacy NDN and operates much more efficiently in scenarios where data objects with unknown names need to be requested. As a result, the Interest traffic of RNR remains independent of the range used which is a great advantage when the possible name-space of an unknown data object is very large. It is also interesting to note that even though the data traffic of RNR increases at first with increasing Range Size, it seems to reach a maximum (truncation point) after some value of the range (around a Range Size of 25 • ) and after that an increase in the range has no effect on the number of returned packets. This effect is attributed to the fact that with a Data Availability of 10%, a Range Size of 25 • is enough to guarantee that every NRC Interest will find at least one data object. A further increase of the range beyond that point will not result in any extra Data packets delivered.

As a final step, we have investigated the effect of a varying network size and a varying mix of consumers and producers in the network on the RNR implementation, in order to establish the trade-offs of our solution against different types of networks. Figure 4 4 that both Interest and Data traffics grow with increasing number of nodes and increasing number of consumers since more consumers means more Interest packets and more Data packets as a response. The corresponding decrease of producers (result of the increase of consumers) does not negatively affect the data traffic in this case, since the number of contents actually remains the same. The only difference is that the same content is now more scarcely placed within the network, evenly distributed among the decreased number of producers. This scarce distribution of content may affect other KPIs such as E2E delay (content available at a producer further away) but this effect can also be counter-balanced by the inherent NDN caching mechanism. We observe that both the legacy and RNR NDN average E2E delays are unaffected by the change in Consumer / Producer ratio for these experiments due to the fact that in both cases the E2E delay is dominated by the time-out penalties enforced. The delay is 10% shorter for the RNR case due to the higher success ratio but in both cases there are a lot of non-ranged requests (since the default value of 10% Traffic Mix is used) which result in several time-out penalties.

The results presented in Figure 4 also indicate that the RNR solution scales very well with network size as well as with content size and/or amount of content producers, which makes it highly adaptable and suitable for a wide range of networks and applications. The legacy NDN on the other hand shows scalability issues which would make it unsuitable, as is, to be implemented in large scale networks and/or networks with a high percentage of unknown names (e.g. massive IoT sensor networks).

Conclusions and Future Work

In this paper we have presented the design, implementation and performance evaluation of Ranged-Name Retrieval, an extension of NDN with support for names with range indications to enable the consumers to request data with partially unknown names. The direct implementation of RNR within the core of the NDN architecture enables it to operate at wire speed and on any NDN node, making it application-agnostic so that data from different applications can be cross-utilized.

Our extensive performance evaluation indicates that RNR manages to address a key issue where legacy NDN is highly inefficient (retrieval of data with unknown names), by significantly improving the network performance (up to 16-fold bandwidth utilization improvement), while at the same time exhibiting a high degree of scalability and imposing minimal overhead (2% additional computation load for realistic scenarios).

The fact that RNR can accommodate varying Range Sizes without increasing the overhead on the nodes, and support multiple ranges within the same Interest (for different name components), makes it highly scalable and adaptable to current of future networks and applications.

Our future work is planned along two main directions, (a) the further development of the RNR scheme and (b) the more detailed testing, evaluation and benchmarking of RNR. As a first step we will extend RNR to support multiple ranges within a single name, each range specifying a search space for a specific component of the name. In this way data objects with inherent tuples in their name, such as latitude and longitude, can be requested while specifying an individual search space for each attribute. New ways to increase the functionality of the range component will also be researched, e.g. combining ranges and data manipulation functions (i.e. to request data aggregates like average, minimum, etc.).

In terms of performance evaluation, a larger variety of scenarios will be tested in the simulator and more extensive KPIs will be used, such as hop count, cache hit ratio and latency, which will allow for a deeper understanding of RNR under different network conditions. Finally, a first version of RNR will be implemented in the TNO IoT testbed, currently under construction, which will consist of dozens of IoT devices / sensors spreading over multiple rooms and floors and running both IP and NDN protocol stack. Experimenting on such a real-life IoT testbed will give us new insights regarding the performance of RNR and the potential issues that may arise or be solved by it, in a true environment.

Fig. 1 :

 1 Fig. 1: Some use cases for RNR. IoT and V2X (left), VR/AR (right)

Fig. 2 :Figure 2

 22 Fig. 2: Average End-to-End (E2E) Delay versus (a) Data Availability and (b) Traffic Mix (% ranged names) Figure 2 depicts the average E2E delay per Interest-Data packet pair, for various Data Availability values (a), and for different ranged request percentages within the Traffic Mix (b).In both cases there is an upper limit of the E2E delay at 1 second (1000 ms) which is caused by the high "miss" ratio of Interests and the resulting enforcement of the time-out penalty (as described in Section 4.2). When Data Availability is very small (Figure2(a), left side), or when only legacy NDN Interests are used to request data with unknown names (Figure 2 (b)), most Interests do not find an appropriate Data packet to return and hence the time-out penalty dominates the E2E delay.

  Figure 2 depicts the average E2E delay per Interest-Data packet pair, for various Data Availability values (a), and for different ranged request percentages within the Traffic Mix (b).In both cases there is an upper limit of the E2E delay at 1 second (1000 ms) which is caused by the high "miss" ratio of Interests and the resulting enforcement of the time-out penalty (as described in Section 4.2). When Data Availability is very small (Figure2(a), left side), or when only legacy NDN Interests are used to request data with unknown names (Figure 2 (b)), most Interests do not find an appropriate Data packet to return and hence the time-out penalty dominates the E2E delay.

Fig. 3 :

 3 Fig. 3: Interest and Data packet bandwidth utilization vs (a) Traffic Mix, (b) Interest Range

Figure 3 (

 3 Figure 3 (b) depicts the bandwidth utilization of Interest and Data traffic for various values of Range Sizes. As the Range Size increases, the Interest traffic for legacy NDN also increases while the Interest traffic for RNR NDN remains

Fig. 4 :

 4 Fig. 4: Traffic on the wire versus consumer percentage and network size (number of nodes) originating from (a) Legacy NDN Interests, (b) Legacy NDN Data packets, (c) RNR NDN Interests and (d) RNR NDN Data packets the same. This can be explained as follows: for the legacy case an increase in the Range Size from 25 • to 50 • means a doubling of Interest traffic since for every data object search a consumer would have to 'flood' 50 sequential legacy NDN Interests instead of 25 resulting in 50*58 = 2900 Bytes on the wire per search instead of 25*58 = 1450 Bytes per search. This phenomenon can be clearly seen in Figure 3 (b). In the case of RNR, however, an increase in the Range Size from 25 • to 50 • would simply mean an update of the relevant name component of the Interest from e.g. /[50-75] to e.g. /[50-100], thus keeping the Interest traffic to a minimum of 58-60 Bytes transmitted per search.As a result, the Interest traffic of RNR remains independent of the range used which is a great advantage when the possible name-space of an unknown data object is very large. It is also interesting to note that even though the data traffic of RNR increases at first with increasing Range Size, it seems to reach a maximum (truncation point) after some value of the range (around a Range Size of 25 • ) and after that an increase in the range has no effect on the number of returned packets. This effect is attributed to the fact that with a Data Availability of 10%, a Range Size of 25 • is enough to guarantee that every NRC Interest will find at least one data object. A further increase of the range beyond that point will not result in any extra Data packets delivered.As a final step, we have investigated the effect of a varying network size and a varying mix of consumers and producers in the network on the RNR implementation, in order to establish the trade-offs of our solution against different types of networks. Figure4is a 3D bar graph depicting the bandwidth utilization for a variety of network sizes (number of nodes) and consumer / producer mixes

  is a 3D bar graph depicting the bandwidth utilization for a variety of network sizes (number of nodes) and consumer / producer mixes showcasing (a) the legacy NDN Interest traffic, (b) the legacy NDN data traffic, (c) the RNR Interest traffic and (d) the RNR data traffic. It is evident from Figure

Table 1 :

 1 RNR simulation parameter settings

	Topology	Barabási-Albert
	Data Availability	1%, 10%, 25%, 50%, 75%, 100%
	Consumers / Producers	90%/10%, 75%/25%, 50%/50%, 25%/75%
	Traffic Mix (% ranged requests)	0%, 10%, 20%, ..., 100%
	Range Size	5, 10, 25, 50, 100
	Number of Nodes	25, 100, 500, 1000, 2000
	Avg. Data Packet Size	10 B, 100 B, 500 B, 1 KB, 1.5 KB


Emilio Ancillotti
email: e.ancillotti@iit.cnr.it

Simone Bolettieri
email: s.bolettieri@iit.cnr.it

Raffaele Bruno
email: r.bruno@iit.cnr.it

RTT-based Congestion Control for the Internet of Things

Keywords: Internet of things, CoAP, delay-based congestion control, flow pacing, Contiki OS

The design of scalable and reliable transport protocols for IoT environments is still an unsolved issue. A simple stop-and-wait congestion control method and a lightweight reliability mechanism are only implemented in CoAP, an application protocol that provides standardised RESTful services for IoT devices. Inspired by delay-based congestion control algorithms that have been proposed for the TCP, in this work we propose a rate control technique that leverages measurements of roundtrip times (RTTs) to infer network state and to determine the flow rate that would prevent network congestion. Our key idea is that the growth of RTT variance, coupled with thresholds on CoAP message losses, is an effective way to detect the onset of network congestion. To validate our approach, we conduct a comparative performance analysis with the two loss-based congestion control methods of standard CoAP under different application scenarios. Results show that our solution outperforms the alternative methods, with a significant improvement of fairness and robustness against unacknowledged traffic.

Introduction

The TCP/IP architecture has significantly evolved over the years to provide new functionalities and efficient support for mobility, content delivery, multimedia applications, etc. Nowadays, there is a large consensus on assuming that one of the most important drivers for the future Internet evolution is the design of solutions to enable access to services and information provided by billions of smart things, i.e. resource-constrained devices with sensing and actuation capabilities [START_REF] Borgia | The Internet of Things vision: Key features, applications and open issues[END_REF]. This network of physical objects embedded with IP-based networking capabilities is commonly known as the Internet of Things (IoT).

IoT networks differ from traditional wired computer networks in several ways. IoT devices are typically battery-powered and have limited computing power. Furthermore, IoT systems often employ low-energy communication technologies,(e.g., IEEE 802.15.4, Bluetooth LE, etc), which operate with smaller MTUs and lower transmission rates compared to traditional wired links. Finally, IoT networks have to rely on mesh communications to cope with limited communication ranges. For these reasons, many IETF working groups (e.g., 6LoWPAN [START_REF] Hui | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks[END_REF], ROLL [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF], CoRE [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF]) have been established to modify the standard TCP/IP stack to fullfill IoT requirements, as well as to develop new protocols [START_REF] Palattella | Standardized Protocol Stack for the Internet of (Important) Things[END_REF]. While important achievements have been obtained, the design of a scalable and reliable transport protocol for IoT deployments is still an unsolved issue.

TCP is the dominant transport layer on the Internet, which provides congestion control and reliable delivery. TCP has been primarily designed to efficiently deliver a large bulk of data over a long-lived connections without strict latency requirements. On the contrary, IoT applications are characterised by different communication patterns as IoT devices typically send small amounts of data either periodically or when sporadic events occur. In addition, IoT applications that implement actuation tasks may request low network delays. Lastly, most TCP congestion control algorithms perform poorly with lossy links, and when MAC transmission delays are similar to or longer than the retransmission timeouts. For these reasons, the Internet architecture for IoT networks only envision the use of an unreliable transport protocol (i.e. UDP). A stop-and-wait congestion control method and a lightweight reliability mechanism are only implemented in CoAP, an HTTP-like web transfer protocol for constrained environments.

CoAP uses the received ACKs to decide when transmitting a new packet. In addition, packet loss is implicitly assumed as a network congestion indicator and an exponential back-off is introduced between retransmissions to reduce sending rates. Recently, CoAP extensions are proposed to provide dynamic retransmission timeout adaptation [START_REF] Betzler | CoCoA+: An advanced congestion control mechanism for CoAP[END_REF]. However, recent studies have investigated the pitfalls of these techniques, such as unfairness and spurious retransmissions when offered loads are close to congestion [START_REF] Bolettieri | Highlighting Some Shortcomings of the CoCoA+ Congestion Control Algorithm[END_REF][START_REF] Ancillotti | Comparison of CoAP and CoCoA+ congestion control mechanisms for different IoT application scenarios[END_REF]. In this work, we investigate an alternative approach for congestion control that employs measurements of round trip times to infer network state and to determine the flow rate that would prevent network congestion. We are inspired by some of the delay-based congestion control algorithms that have been proposed for the TCP under specialised conditions (e.g. data centres [START_REF] Mittal | TIMELY: RTT-based Congestion Control for the Datacenter[END_REF] or high-speed networks [START_REF] Liu | TCP-Illinois: A loss-and delay-based congestion control algorithm for high-speed networks[END_REF]). One of our aims is to show that reliable RTT measurements can be obtained in constrained environments with limited additional overheads. Differently from other similar schemes, we do not use fixed RTT thresholds to predict the onset of congestion. Instead, we leverage RTT variability to define a rate control scheme that aims at maintaining a low probability of data transaction losses. Our insight is that in 6LoWPAN networks RTT measurements are not a deterministic function of queue delays and propagation times, while the growth of RTT variance is a more efficient indication of network load increases. To prove our claims we implement the proposed rate control algorithm in CoAP, and we conduct a comparative performance analysis with the two loss-based congestion control methods of standard CoAP under different application scenarios. Results show that our solution outperforms the alternative methods, with a significant improvement of fairness and an increase of packet delivery ratios in presence of unacknowledged traffic.

The rest of this paper is organised as follows. Related works are discussed in Section 2. The proposed RTT-based congestion control method for CoAP is presented in Section 3. In Section 4 we introduce the simulation setup and we present the performance evaluation results. Finally, concluding remarks are discussed in Section 5.

Background and Related Works

The design of congestion control algorithms for reliable transport protocols in wired and wireless networks is a deeply investigated topic. In the following, we discuss the key design principles of congestion control solutions for TCP [START_REF] Afanasyev | Host-to-Host Congestion Control for TCP[END_REF]. Then, we present a brief overview of CoAP and its congestion control mechanisms.

TCP congestion control

The majority of existing end-to-end congestion control proposals for TCP are based on the congestion window concept. Specifically, the congestion window is an estimate of the maximum number of unacknowledged data packets that a TCP flow can transmit without congesting the network. Thus, the TCP transmission rate can be indirectly controlled by adjusting the congestion window size. Typically, TCP senders update their congestion windows based on feedback signals they receive from the network. The most popular TCP congestion algorithms, such as TCP NewReno and its many variants, use packet losses as a binary congestion control signal1 . However, loss-based congestion control algorithms are reactive schemes because they reduce sending rates only when network congestion causes a packet loss. The seminal work of TCP Vegas [START_REF] Brakmo | TCP Vegas: End to End Congestion Avoidance on a Global Internet[END_REF] introduces a proactive congestion avoidance method that tries to quantify the congestion state of the network before a congestion event occurs using round-trip delays. Specifically, the minimal RTT value is considered a baseline indicating a congestion-free network state. Then, the congestion window is decreased if the delay increases. Other modern TCP variants, such as FAST TCP and Compound TCP, use delay-based congestion control algorithms trying to maintain buffer occupancy at the bottleneck queue around some predefined thresholds. The advantage of such schemes is that they can stabilise the network around the full utilisation. The inherent weakness of delay-based algorithms is that their performance degrades if the delay measurements are noisy (e.g., due to delayed ACKs and route changes). Furthermore, minimum RTT can be a bias estimate of queuing delays in a non congested network. For these reasons, delay is typically used in hybrid congestion control schemes as a secondary congestion signal in addition to packet loss information [START_REF] Liu | TCP-Illinois: A loss-and delay-based congestion control algorithm for high-speed networks[END_REF].

CoAP

The Constrained Application Protocol (CoAP) is a web transfer protocol based on a REST architecture with a Request/Response interaction model. Requests and responses can be carried in non-confirmable (NON) or confirmable (CON) messages. The latter are required to be acknowledged once received by the destination endpoint. Reliability is then implemented by detecting message losses and retransmitting the packet (until a maximum number of attempts). Packet losses are detected by using retransmission timeouts (RTOs): RTO is set by the sender when a CON transaction starts; If the RTO expires before the ACK reception, the packet is retransmitted.

In CoAP, the congestion control regulates CON transmission: packet losses are interpreted as a congestion signal; therefore, retransmissions are spaced out using a binary exponential back-off (BEB) policy (RTO doubled at each retransmission). By default, the initial value for the RTO is randomly chosen from a fixed interval. Furthermore, the number of parallel outstanding transmissions towards the same destination is limited to NSTART, which is set to one in standard CoAP (i.e., no more that one notification per RTT to a client on average).

A more advanced congestion control scheme is proposed in CoCoA+ [START_REF] Betzler | CoCoA+: An advanced congestion control mechanism for CoAP[END_REF], which introduces an algorithm to dynamically adjust the RTO using measured RTTs. The key idea is to overcome the drawbacks of having a fixed RTO that could underestimate node's RTTs leading to unnecessary retransmissions or that could overestimate them leading to increased transaction delays. Specifically, CoCoA+ maintains two RTO estimators for each destination: a strong RTO estimator (RT O s ) uses RTT samples that come from transactions which did not require a retransmission, and weak RTO estimator (RT Ow) that uses RTT samples of transactions that required less than three retransmissions. Individual RT Ox, where x ∈ {s, w}, are computed using the following formula:

RT O x = SRT T x + K x * RT T V AR x , (1)
where SRT T x and RT T V AR x denote the smoothed RTT and RTT variation respectively, as defined in RFC 6298 [START_REF] Paxson | Computing TCP's Retransmission Timer[END_REF]; K s is set to 4, while K w is set to 1. Upon ACK reception, the computed RTO sample (weak or strong depending on the nature of the last sampled RTT) is used as input for a classical exponential moving average filter to calculate the RTO for the next CON transaction (RT O init ). A smaller K w and a smaller weight for weak RTO estimates are used to avoid large increments in RT O init due to large RT T V AR w , which is affected by the high variability of RTT measurements of retransmitted messages.

Furthermore, CoCoA+ introduces a new back-off policy where the multiplicative factor, used to update the RTO, is variable and depends on the RT O init value. Ideally, this should avoid that with short RTOs all retransmissions are occurring in a short interval, and that, on the contrary, with large RTOs unnecessary delays are introduced. Finally, CoCoA+ proposes an ageing scheme for the RTO estimate. Specifically, if no RTT samples are collected for a sufficiently long period of time, the RTO values should converge toward their initial value.

RTT-CoAP Design

RTT-CoAP is an extended version of the standard CoAP web transfer protocol that implements our RTT-based congestion control scheme for 6LoWPAN networks. Unlike classical TCP that employs a window-based congestion avoidance method, RTT-CoAP uses a rate-based algorithm that directly controls the pacing rate of packet transmissions to reduce traffic burstiness and data losses. As discussed in Section 1, we are inspired by recent delay-based congestion control protocols that rely on delay measurements for inferring network congestion [START_REF] Hayes | Revisiting TCP Congestion Control Using Delay Gradients[END_REF][START_REF] Mittal | TIMELY: RTT-based Congestion Control for the Datacenter[END_REF]. The typical pitfalls of most delay-based congestion control schemes is that it is difficult to obtain a reliable estimate of RTT trends, especially in wireless networks. Furthermore, in constrained environments with small buffers and low transmission rates, RTT can not be considered a deterministic function of the queuing and propagation delays. Thus, it is not easy to define a RTT baseline that is indicative of network congestion. Most solutions simply assume that the minimum of all measured RTTs is the RTT value of a non-congested connection. However, the random channel access method employed in the 802.15.4 MAC standard, which cause huge variability of channel access delays, and bursty packet arrival processes leads to sudden fluctuations in RTT measurements. Furthermore, changing network conditions or network paths generate varying RTT measurements. Thus, single RTT values or the difference between RTT values may not be indicative of the network state. In the following, we explain our RTT measurement framework and how we leverage RTT variations to classify the different network states. Depending on the current network state coupled with thresholds on data transaction losses, RTT-CoAP updates the sending rate of each CoAP source to stabilise network delays and prevent packet losses.

Monitoring RTT variations

We assume that a CoAP sender can use ACKs to obtain RTT samples. Specifically, an RTT measurement is obtained as the difference between the transmission time of a CON CoAP message and the time in which the ACK is received. According to Karn's algorithm [START_REF] Paxson | Computing TCP's Retransmission Timer[END_REF], RTT samples should not be taken from packets that were retransmitted, as it is ambiguous to assign the ACK message to the first transmission of that packet or to later retransmissions. To remove this ambiguity we introduce the CoAP timestamp option: the CoAP sender places a timestamp in each CON message, and the CoAP receiver echos these timestamps back in the ACKs. Timing each CoAP message leads to a better RTT estimator without generating excessive protocol overheads, as discussed in Section 3.3.

Inspired by the TCP rules for computing retransmission timers [START_REF] Paxson | Computing TCP's Retransmission Timer[END_REF], we exploit RTT samples to compute three state variables SRT T L , SRT T S , and RT T V AR L . The first two state variables are obtained by applying exponential smoothing to RTT samples. The third state variable is the well-known smoothed estimate of RTT variations as computed in TCP. Unlike CoAP, we do not distinguish between weak and strong estimators but we use all CON messages to update the RTT state variables. More formally, let r be the latest RTT sample that is obtained by a CoAP sender. It holds that

SRT T S = α S r + (1 -α S ) × SRT T S ( 2
)
SRT T L = α L r + (1 -α L ) × SRT T S (3)
RT T V AR L = β L |SRT T L -r| + (1 -β L ) × RT T V AR L , (4)
with α S >> α L . Using a small smoothing factor α L is useful to remove the impact of noise on RTT measurements (e.g., due to random backoffs, or bursty packet arrival processes), and to obtain a more accurate estimate of the longterm RTT trends. On the other hand, using a large smoothing factor α S is needed to monitor short-term RTT differences that occur due to sudden changes of network conditions. As better explained in the following, this improves the responsiveness of the rate control technique, especially when RTT samples are infrequent due to long network delays or low traffic intensity. It is important to point out that constrained devices have very limited memory, which makes impractical to implement more sophisticated averaging filters that require a long measurement history.

Our key idea is that the growth of RTT variance is a good indication of network state as a contention increase leads to longer backoff intervals, and higher variability of channel access delays. Thus, we leverage RT T V AR L variable to define characteristic regions of the network state, which will be used to determine the direction of sending rate changes (i.e., whether sending rates of CoAP sources should be increased or decreased). Let S denote the network state at the reception of an ACK. Furthermore, let us define the decision boundary T (γ) as follows:

T (γ) = SRT T L + γ × RT T V AR L . (5)
To some extent, T (γ) is analogous to a confidence level of the mean RTT, as it is a measure of RTT variability and it can be used to assess the distance of RTT samples from the mean. Now, we can identify four characteristic regions using the following decision boundaries:

-(LC): SRT T S < T (-1) (low congestion). In this state we can assume that there is no congestion in the network, as the short-term RTT estimate is well below the long-term averages. Thus, the sending rate can be aggressively increased. -(NO): T (-1) ≤ SRT T S < T (+1) (normal operating point). In this state, the short-term RTT estimate is comparable to typical RTT measurements. This corresponds to a normal operating point and the sending rate should left unchanged. Depending on the experienced packet losses a moderate increase of sending rates is also possible to check if more bandwidth is available. -(MV): T (+1) ≤ SRT T S < T (2) (medium variability). In this state, shortterm RTT variability grows and this can be a signal of ramping network congestion. Thus, a controlled decrease of sending rate can be necessary to avoid congestion. -(HV): SRT T S ≥ T (+2) (high variability). In this state, the short-term RTT estimate is significantly higher that the long-term RTT estimate. Thus, the CoAP source needs to aggressively reduce the sending rate so as to return to the normal operating state as soon as possible.

Rate control algorithm

Algorithm 1 shows the pseudo-code for our rate adaptation scheme. RTT-CoAP maintains a single sending rate R for each connection and updates it on every ACK reception using the above-described state variables, coupled with a measure of the probability of data transaction loss. Specifically, each CoAP sender maintains also an exponential moving average, say µ, of the probability that a confirmable CoAP message is retransmitted. Since RTT-CoAP aims at keeping this probability very low, it employs two thresholds to respond to extreme cases of high packet losses or possible underutilisation of available bandwidth. We are inspired by the idea of control dead zones in TCP Vegas, which defines a range of network delays that correspond to a steady state during which no changes are applied to the sending rate. This approach is known to mitigate the impact of network condition fluctuations and to facilitate the convergence to a stable behaviour. More formally, we define L high as an upper bound of the tolerable CoAP message loss ratio. It provides a way to infere that there is no more available bandwidth for the CoAP sender. Moreover, we define a low threshold L low to filter out RTT spikes: RTT fluctuations above the normal operating region are not taken into consideration when the loss ratio is lower than L low . The rate adjustments in the various states are described in detail in the following. At the reception of a ACK the CoAP sender updates the RTT state variables and the CoAP message loss ratio, and it determines the new sending rate. Basically, there are four possible conditions:

1. S ∈ LC and there is a fast increase of sending rate (see line 3). 2. S ∈ NO and there is a slow increase of sending rate (see line 5).

3. S ∈ MV and there is a slow decrease of sending rate (see line 7). 4. S ∈ HV and there is a fast increase of sending rate (see line 9).

However, if µ < L low we can safely assume that no congestion is experienced. As a consequence, the decreases of sending rates are disabled (see lines 6 and 8).

On the other hand, if µ > L high the network is very likely operating under congestion state, and the increase of sending rates in the normal operating region should be disabled (see line 4). Concerning the rate adaptation, RTT-CoAP probes for more bandwidth by performing an additive increment step. However, the bandwidth additive increment is not constant. Specifically, RTT-CoAP differentiates between two regimes: a sending rate that is smaller than one CoAP message per RTT (called base rate, see line 18), and a sending rate that is higher than this value. In the first case, the rate increase will be proportional to the difference between the base rate and the current rate. In the latter case, the rate increment is a fraction of the base rate. The rationale of this design choice is to avoid that CoAP sources that already transmit faster than the base rate get a disproportionate advantage in comparison with slower flows. As in TCP Vegas, we follow an additive increase/additive decrease (AIAD) policy. Thus, when

18: R b = 1 SRT T L 19: if (R < R b ) then 20: δ = ω × (R b -R) 21: else 22: δ = ω × R b 23:
end if return δ 24: end function network congestion is detected and the sending rate has to be decremented, a linear decrement factor δ is selected following the aforementioned rules.

RTT-CoAP Implementation

In this section we describe the key points of our implementation of RTT-CoAP leveraging Contiki, an open source operating system for the IoT. In particular, we use CoAP Erbium, a C implementation of CoAP for Contiki, that is compliant with RFC 7252 [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF] and supports blockwise transfers and observing.

CoAP specification defines a number of options that can be included in a message. Specifically, CoAP uses a short fixed-length binary header (4 bytes) that may be followed by compact binary options and a payload. Each option instance in a message specifies the option number of the defined CoAP option, the length of the option value, and the option value itself. Since a length of a timestamp is typically four bytes, we follow an alternative approach for timing the CoAP messages. Specifically, the CoAP senders stores within a local table the timestamp of each transmissions of the same CoAP message, and use the retransmission counter as a one-byte timestamp option. The transmission counter is echoed in the corresponding ACK and it is used in the CoAP sender to retrieve the correct transmission time, and to estimate the RTT without ambiguity. Finally, we mark the CoAP timestamp option as: i) a critical option, i.e., it must be understood by the receiving endpoint in order to properly process the message; and ii) a safe-to-forward option, i.e., it can be safely forwarded by a proxy even if it can't process the option. The default value of this option is 0.

In this section, we give the details on the simulation setup used to compare standard CoAP-CC, CoCoA+ and RTT-CoAP. Then, we presents results for a variety of different scenarios.

Simulation setup

For our performance comparison we conduct simulations in Cooja, a simulation platform included in Contiki toolset, that allows to emulate off-the-shelf wireless sensor node harwdare. At the physical (PHY) and MAC layers, the nodes implement IEEE 802.15.4, using a transmission rate of 250 kbps in the 2.4 GHz radio band. We do not use radio duty cycling (RDC) at the MAC layer to mitigate RTT fluctuations. To model realistic radio propagation and interference we use the Ray-tracer Medium (MRM), configuring MRM parameters to achieve a 100% success rate at 10 meters and an interference range of 20 meters.

RPL is used as routing protocol [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. We consider two large network scenarios with 57 and 112 sensor devices, respectively. The nodes are deployed along concentric circles, and the distance between consecutive circles is 10 meters. Nodes are CoAP servers that send observing notifications toward a common data collector node placed at the center of the network. We will assume that each server can generate two kinds of data flows: i) a data flow made of NON-messages (background traffic); and ii) a data flow made of CON-messages (reliable traffic). The main performance metric is the aggregated goodput measured as the number of successfully received acknowledgments (i.e. successfully completed transactions), and expressed in Kbit per seconds (Kbps). We also computed the flow fairness with the well-known Jain's Index applied to goodput measurements.

Mixed traffic

The first set of experiments assumes that both background traffic and reliable traffic are active on the same CoAP source. The goal of this scenario is to assess the impact of an increasing congestion-unaware traffic on the reliable flow, which is instead regulated by the congestion control mechanism. More in detail, the reliable traffic has a packet generation rate of approximately 1Kbps per CoAP source and it is maintained constant for the whole simulation. Such rate ensures that there is always a packet ready to be sent, thus, reliable traffic follows an asymptotic behaviour. Instead, the sending rate of the background traffic evolves as follows; it starts with an aggregate value of approximately 2Kbps, and it is incremented every 400 seconds until reaching a maximum of about 44 Kbps, and finally it is reverted to 2Kbps.

In Figure 1a and Figure 1b we show the instantaneous goodput carried by the different protocols for n = 57 and n = 112, respectively. For convenience, we report the rate of the background traffic with a solid black line.

The results reported in Figure 1a show that when the network is not congested, RTT-CoAP achieve a slightly lower aggregate goodput compared to both CoAP and CoCoA+ (the difference in goodput is compensated by a sensible increase of the fairness index as showed in Figure 2a). However, as the background traffic increase RTT-CoAP tends to outperform both CoAP and Co-CoA+, achieving about the same aggregate goodput in the presence of medium congestion (simulation time between 100min and 105min), and obtaining a sensible goodput improvement in the presence of high congestion. We can observe that when the background traffic reaches its maximum value the CoCoA+ flows almost completely stall. The main reason is that CoCoA+ (as CoAP) indirectly regulates the sending rate using RTO, which under consecutive losses can grow up to very large values [START_REF] Bolettieri | Highlighting Some Shortcomings of the CoCoA+ Congestion Control Algorithm[END_REF][START_REF] Ancillotti | Comparison of CoAP and CoCoA+ congestion control mechanisms for different IoT application scenarios[END_REF], thus leading to nodes not sending data at all. Interestingly, CoAP is more resilient against non-confirmable traffic than CoCoA+ as RTO values are chosen in a fixed interval. On the other hand, RTT-CoAP can detect the onset of congestion earlier than CoCoA+, and it adjusts the pacing rate before overwhelming the network. Similar conclusions can be drawn from Figure 1b. However, we can see that the gap between the algorithm is reduced when the number of sources increases. This can be explained by observing that CON traffic is asymptotic. Thus, it is enough that a few CoAP sources are able to get access to the channel to be able to saturate the available bandwidth. As better explained in the following, the downside of this asymptotic behaviour is an unfair share of the network bandwidth among the existing flows.

In Figure 2a and Figure 2b we show the fairness that is measured in the same settings of the above figures. The results clearly show that our proposed congestion control solution is able to significantly outperform both standard CoAP and CoCoA+ in terms of fairness, even when the network is deeply congested.

Homogenous traffic

This second set of experiments assumes that each CoAP source generates only reliable traffic. The rate at which the application send the data to the CoAP layer is incremented every 300 seconds. The goal of this scenario is to assess the efficiency of our rate-based congestion control mechanism to fully utilise the available bandwidth while maintaining a fair share of network resources between the CoAP sources. To this end, Figure 3a and Figure 3b show the instantaneous goodput carried by the different protocols for n = 57 and n = 112, respectively, while Figure 4a and Figure 4b show the fairness index in the same scenarios. The results confirm that although the aggregate goodput achieved by RTT-CoAP is slightly lower than that achieved by CoAP and CoCoA+, RTT-CoAP guarantees a significantly higher fairness among different traffic sources.

In particular, we observe an increment of the fairness index of about 250% when the offered load is set to the maximum value (simulation time between 110min and 115min Figure 4b), while the goodput decrease is below 10%.

Conclusions

In this paper we have proposed RTT-CoAP, a novel RTT-based congestion control scheme for CoAP. Our key idea was to monitor long-term and short-term RTT trends to classify network state and to proactively anticipate network congestion. Differently from other delay-based congestion control scheme our solutions doe not require to define fixed RTT thresholds that avoid congestion, but we leverage the growth of RTT variance to directly adjust the sending rate of each CoAP source. In comparison to basic CoAP and CoCoA+, RTT-CoAP ensures a significant improvement of fairness, and an increase of packet delivery ratios in presence of congestion-unaware traffic.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Goodput under mixed traffic scenario for two network deployments.

Fig. 3 .Fig. 4 .

 34 Fig. 3. Goodput under mixed traffic scenario for two network deployments.

  SRT T L , SRT T S , RT T V AR L ,µ)

	2:	if (S ∈ LC) then
	3:	R = R + compRate(R, SRT T L , f ast);
	4:	else if (S ∈ NO) AND (µ < L high ) then
	5:	R = R + compRate(R, SRT T L , slow);
	6:	else if (S ∈ MV) AND (µ ≥ L low ) then
	7:	R = R -compRate(R, SRT T L , slow);
	8:	else if (S ∈ HV) AND (µ ≥ L low ) then
	9:	R = R -compRate(R, SRT T L , f ast);
	10:	end if
	11: end function
	12: function compRate(R, SRT T L , speed)
	13:	if (speed = f ast) then
	14:	ω = 0.2
	15:	else if (speed = slow) then
	16:	ω = 0.05
	17:	end if

VIII Algorithm 1 RTT-CoAP congestion control 1: function updateRate(S,

Typically, TCP packet losses are detected through the receipt of duplicate and/or selective ACKs, or the timeout of a retransmission timer.

This work was supported by the SIGS project, funded by the region of Tuscany under the FAR-FAS 2014 framework.


Mehrnoosh Monshizadeh
email: mehrnoosh.monshizadeh@nokia-bell-labs.com

Vikramajeet Khatri
email: vikramajeet.khatri@nokia-bell-labs.com

Buse Atli
email: buse.atli@aalto.fi

Raimo Kantola
email: raimo.kantola@aalto.fi

An Intelligent Defense and Filtration Platform for Network Traffic

Keywords: Security, Cloud computing, Internet of Things, Machine Learning, Anomaly Detection

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Although the Intrusion Detection System (IDS) is considered as a well-known mechanism to monitor and detect malicious traffic in communication networks, the cost and high processing time is a challenge to handle large amount of data. Moreover, IDSs and all other detection systems or mechanisms are applicable for known attacks rather than unknown or new attacks. Data Mining (DM) is a technology that uses highly developed and complex algorithms for processing large volume of data [START_REF] Desale | Genetic algorithm based feature selection approach for effective intrusion detection system[END_REF]. However, complexity of mentioned algorithms in [START_REF] Desale | Genetic algorithm based feature selection approach for effective intrusion detection system[END_REF] results to high computation time. In order to solve this problem, network traffic flow control in combination with DM techniques are proposed in this paper. The protocol analyzer in this platform classifies and filters vulnerable protocols to avoid unnecessary computation load. On the other hand, each data set includes hundreds of features that may cause performance degradation in detection process. To overcome this problem, feature selection methods are used to select less number of features and reduce the dimensions of the dataset [START_REF] Desale | Genetic algorithm based feature selection approach for effective intrusion detection system[END_REF]. In addition, the use of linear algorithms in conjunction with learning algorithms improves accuracy and computation time. Linear algorithms will detect the attack in general level regardless of their types while learning algorithms cluster the attacks in different categories. This mechanism decreases the load of input data for the learning algorithm that is the most time consuming part because of its complex structure [START_REF] Monshizadeh | Security Related Data Mining[END_REF].

The rest of the paper is organized as follows. Section 2 briefly reviews related work and research motivation. Section 3 describes the Hybrid Anomaly Detection Model (HADM) architecture. Section 4 discusses the implementation and results. The discussion on future work presented in section 5 and last section concludes the paper.

Related Work and Research Motivation

Di Pietro et al. [START_REF] Di Pietro | Dynamic deep packet inspection for anomaly detection[END_REF] proposes anomaly detection using Deep Packet Inspection (DPI) and machine learning methods upon selected captured packets. Based on output from machine learning method, the packet capture criterion is adjusted again to capture further packets and again fed into DPI and machine learning methods. The machine learning model may use k-Nearest Neighbor (k-NN), replicator nearest neighbor, Bayesian networks, k-means, Artificial Neural Networks (ANN) and Support Vector Machines (SVM) algorithms. However, the learning process of algorithm is not explained and packet capture criterion does not consider taking all packets for one or more protocols. Vasseur et al. [START_REF] Vasseur | Anomaly detection in a network coupling state information with machine learning outputs[END_REF] proposes an approach for training supervised learning classifiers for effective detection and cites Deep Neural Networks (DNN) classifier as an example. The study mentions Distributed Denial of Service (DDoS) attacks. Security device in this study refers to firewall, IDS, Intrusion Prevention System (IPS) etc.; which use traffic signatures to access traffic in the network. Distributed learning agents refer to components or modules which use machine learning based anomaly detection to analyze or access traffic in the network. A supervisory device in the network receives traffic from both security device and distributed learning agent; and combines the received traffic to train the classifier. Then, the supervisory device assigns the trained classifier to one or more distributed learning agents. Since, the challenge in the supervised learning classifiers is the labelled training data, this study aims to optimize training by continuously providing the labelled data. However, this study does not consider other machine learning methods, does not use protocol analyzer for filtering the traffic to be analyzed considering the traffic bandwidth and traffic collection period in order to reduce the load.

In the study by Piettro et al. [START_REF] Di Pietro | Signature creation for unknown attacks[END_REF], a network trains and generates an expected traffic model based on a set of training data. The device receives an unexpected behavior notification from a particular node based on a comparison between the expected traffic model and an observed traffic behavior by the node. The particular node also prevents the machine learning attack detector from analyzing the observed traffic behavior. The device updates the machine learning attack detector to account for the observed traffic behavior. This method receives a model of normal traffic behavior. The Signature Generator Entity (SGE) compares the input data with the expected normal traffic models. If they are different, SGE generates a signature for the attack class and trains the ANN accordingly with new information for the next detection phase. This model may have high false positive rate since it compares input traffic only with an expected model.

In the study by Yadav et al. [START_REF] Yadav | Network behavior data collection and analytics for anomaly detection[END_REF], network traffic data is collected from several sensors, distributed and installed into network components. The network traffic data comprises process, user and host information. The analytics module inside a network device or Virtual Machine (VM) identifies anomalies within the network traffic data based on dynamic modeling of network behavior. The anomaly detection in this study is based on the honeypot to collect labelled malicious network traffic as an input to the anomaly detection unit comprising of unsupervised and supervised machine learning algorithms. The honeypot relies only on received attacks and not the other attacks. This study points in general dynamic machine learning.

In this study we propose a platform compromises of two main parts where each part independently increases the efficiency of attack detection based on the factors such as precision, recall, accuracy and computation time. While part 1 of the model utilizes some algorithms and the protocol analyzer for traffic filtration, reducing the processing time and increasing the accuracy, the part 2 applies a dynamic feature selection with genetic algorithm to classify unknown attacks and increase the accuracy as well.

The HADM model comprises a protocol analyzer, linear and learning algorithms as well as other modules. Since some protocols such as streaming protocols are not vulnerable and attackers usually target specific protocols, protocol analyzer in this platform classifies and filters vulnerable protocols to avoid unnecessary computation load. Protocol analyzer forwards the filtered traffic either to a linear algorithm only for Denial of Service (DoS) detection or to a combination of a linear and a learning algorithm for other types of attacks. The linear algorithm initially defines if the traffic is secure or unsecure regardless of the attack type. In addition, it extracts the proper features in order to provide them to a learning algorithm in order to classify already known attacks and detect unknown attacks. The other counter measurement located after the learning algorithm extracts information for known attacks (which network is already protected against them) from other deployed security mechanisms in the network e.g., firewall, IDS, DPI etc. It compares the extracted information with the attack received from the linear algorithm and drops the similar attacks. In each step, a feedback is sent to a database for next level detection. In the learning algorithm, the received attack is assigned to one of the attack clusters. In addition, algorithm changes its structure and input weights dynamically based on the received feedback. If the attack does not belong to any of the mentioned clusters, it is assigned to a totally new cluster. This novel mechanism dynamically defines new features in order to detect new types of attack.

Architecture

As it is shown in Fig. 1, the HADM functionality is divided into three phases: protocol analyzer, dynamic machine learning and validator & database.

Protocol Analyzer

The first phase of the proposed HADM is called protocol analyzer which filters vulnerable protocols. The protocol refers to communication protocol over which the traffic is carried on such as HyperText Transfer Protocol (HTTP) and Transmission Control Protocol (TCP). As it is shown in Fig. 2, protocol analyzer consists of five modules.

Fig. 1. HADM on operational level in brief

Decision module. This module includes a list of vulnerable protocols which are predefined and also dynamically updated based on the received feedback from log file via database. Some protocols such as HTTP and TCP are well known vulnerable protocols while others like Real Time Streaming Protocol (RTSP) could be a safe protocol. It checks whether traffic is carried on any of the listed vulnerable protocol.

Fig. 2. Protocol Analyzer

Counter and Prioritization module. The function of this module is based on the occurrence threshold (n) and prioritization. It means that if the vulnerable protocol carries suspected traffic for n times, then this module will forward the suspicious traffic to the next layer for detection and labelling. The idea is to cycle all possible vulnerable protocols over an agreed time window (1 hour, 1 day etc.). The module only keeps a certain number of vulnerable protocol in the list which is based on prioritization. For example, if we already have 20 vulnerable protocols and 21 st comes up, then the counter must prioritize only 20 of these protocols. The prioritization is based on the counting occurrence over the time window. The sole purpose of this technique is to reduce the computation load of traffic analysis.

Feature Extraction. It extracts the best features from the suspicious protocol. This module is utilized in second phase as well.

Learning Algorithm I. If the protocol (that carries the input traffic) is not listed as vulnerable, traffic is still sent to this learning algorithm for analysis and reconfirmation. The learning algorithm I will check whether the protocol is vulnerable or not. Our proposed platform is tested with Extreme Learning Machines (ELM), Self-Organizing Map (SOM) and MultiLayer Perceptron (MLP) algorithms.

Log file. Every time the learning algorithm I in the protocol analyzer detects a new vulnerable protocol, it is recorded into the log file and a feedback will be sent to decision module via database. The log file records packet features such as time stamp, packet size, Internet Protocol (IP) header and information on other layers (Ethernet, TCP, application layer).

Dynamic Machine Learning

The second phase of the proposed HADM combines linear and learning algorithms for efficient attack detection. As it is illustrated in Fig. 3, dynamic machine learning consists of the following modules in addition to feature extraction that has been explained earlier. is considered for this module in order to avoid overloading the rest of the proposed hybrid model. However, the decision tree algorithm can be replaced based on the operator demand, we have considered it due to its low processing time.

Rule Extractor and Deduplicator. This module filters the known attacks that system is already protected against, by using other deployed security mechanisms and forwards other attacks to learning algorithm II for labelling. A set of rules are extracted from those deployed security mechanisms in the network, the extracted information is compared with received attack from linear algorithm I and is dropped if it is similar. Rules in this module are updated dynamically based on input from the parallel security mechanisms.

Learning Algorithm II. This module is the last detection layer. Initial features and clusters are defined for the algorithm during the training process in order to cluster different attacks such as Botnet attack (B) and Malicious codes (M). At first, the traffic is labelled to one of the clusters based on their similarity or distance. Since the traffic that arrives to this module has been already identified as attack, if it does not belong to any of the mentioned clusters then it is considered as new type of attack (N) and a cluster will be created for it. The features of the new type of attack (N) must be added to the algorithm accordingly. The implementation of the proposed platform with Artificial Neural Networks (ANN) and Genetic Algorithm (GA) is already ongoing by authors and results will be presented in future paper. Other potential unsupervised algorithms can be SOM and hierarchical clustering.

Validator & Database

The last phase of the proposed HADM validates detected attacks, stores them into the database and shares the updates to all relevant modules. It consists of following modules as shown in Fig. 4.

Fig. 4. Validator & Database

The validator acts similar to error detection module in order to decrease False Positive (FP) and False Negative (FN) rates. If the actual result differs from expected result then result is considered as error and is not registered in the database (DB). Validator should be always updated with labeled data and output from detection algorithms. The database saves all the results of detection algorithms; from each algorithm, a sample of

Validator Input from Phase 1 or 2

Updates to Phase 1 and Phase 2 : FP, FN Database the outcome (feedback) is sent to database that will be used in the future detection. A database contains known attacks, new attacks and dropped attacks.

Implementation Phases

As it is shown in Fig. 5, the implementation of HADM platform is divided into two parts. Due to space limitation, the part 1 is presented in this paper while the implementation and experimental results of part 2 will be published in a separate paper. In this section, we first introduce the algorithms and feature extraction methods that are applied for mentioned algorithms. Next, we describe the selected datasets for the experimental study. Finally, we present the measures employed to evaluate the performance of each algorithm independently and also for the integrated scenario.

Fig. 5. Hybrid Anomaly Detection Model (HADM)

Applied Algorithms

In order to evaluate HADM, different algorithms including ELM, MLP (with 10 and 50 hidden nodes), k-Nearest Neighbor (k-NN), Support Vector Machine (SVM), Decision Tree (DT) and Logistic Regression (LR) are applied. In addition, our simple Decision maker algorithm (Algorithm D) is used in protocol analyzer to filter vulnerable protocol. The algorithm D is shown in Fig. 6.

Feature selection

The original dataset contains 27 features as shown in Table 1.

Data Preprocessing

The ISCX-2012 dataset exhibits realistic network behavior and contains diverse intrusion scenarios. The dataset includes network traffic on HTTP, SMTP, SSH, IMAP, POP3, and FTP protocols with FTP and SSH password brute force, Java based Meterpreter, Add new Superuser, Linux Meterpreter payload and C100Webshel attacks [START_REF] Atli | Anomaly-Based Intrusion Detection by Modeling Probability Distributions of Flow Characteristics[END_REF]. To evaluate HADM efficiency, the modified version of the ISCX-2012 [START_REF]ISCX-2012[END_REF] dataset with diverse attacks have been used. Since the ISCX-2012 dataset lacks the DoS attack on UDP protocol, we extracted the UDP DoS from UNSW-NB15 dataset [START_REF]The UNSW-NB15 data set[END_REF] and injected to the ISCX-2012 dataset. The final dataset is classified in three categories: normal, attack and unknown. The IP address and hex MAC address of the applied dataset are transformed into separate numeric attributes to improve the performance of the algorithms.

Table 3 shows the distribution of each intrusion type in the training and testing data.

Experimental Results

All the experiments are carried out on a workstation with Intel core i5 Quad @2.6GHz, 16 GB RAM, 500GB HDD. The scripts were developed in Python in a Linux environment. All applied algorithms in the evaluation process of HADM are trained once and saved for the future tests. However, currently platform is tested on single workstation, the whole functionality can be installed on several VMs for load balancing and decentralized monitoring purposes in order to handle large amount of traffic at core network.

The similar mechanism has been explained in other papers presented by authors on SDN security [START_REF] Monshizadeh | Detection as a service: An SDN application[END_REF].

As it is shown in Table 4, for learning algorithm I, testing time, total accuracy score, binary cross entropy error and false negative score are compared and MLP methods outperforms the ELM approach. The binary cross entropy error and the false negative score of ELM is quite high, which means that in most cases, it fails to give alarm when an intrusion occurs. If MLP with 10 and 50 hidden layer neurons are compared, it can be seen that MLP with 50 hidden layer neurons performs slightly better than the MLP with 10 hidden layer neurons in terms of differentiating the normal and attack traffic, although the time complexity for the testing is smaller with MLP with 10 hidden layer neurons. Since the overall architecture has a high time and model complexity with many preprocessing (protocol analyzer) and post-processing (genetic algorithm etc.) steps, we have chosen MLP with 10 hidden layer neurons for this module to reduce the overall processing time for labelling an incoming network packet and the model complexity.

To evaluate part 1 of HADM as whole and with protocol analyzer functionality, the traffic carried on vulnerable protocol will be directed to k-NN and LR and the rest of the traffic to ELM/MLP. Training in this phase is covered in two scenarios. In the scenario I, the incoming traffic to k-NN includes: UDPDoS+TCPDoS while the LR algorithm processes the rest of the traffic (TCP-TCPDoS). In Scenario II, all UDP traffic will be forwarded to k-NN algorithm and all TCP traffic to LR algorithm. Table 5 and Table 6 show the performance evaluation for testing scenario I and II based on three metrics. The precision and recall values are measured for attack class.

As it is shown in Table 5, Table 6 and Table 7, the computation time decreased greatly in scenario II, while the accuracy, precision and recall factors also improved. That means the HADM outperforms considerably while UDP DoS is separated from attacks carried over TCP (applying protocol analyzer). However, in this study, we only classified our input data to three categories of normal, attack and unknown and have not applied the part II of HADM yet to categorize different types of attacks, which is a factor to consider in our future work. The proposed model compromises of two main parts where each part independently increases the efficiency of attack detection based on the factors such as precision, recall, accuracy and computation time. While part 1 of the model utilizes the protocol analyzer and mentioned algorithms are implemented for traffic filtration, reducing the processing time and increasing the accuracy, the part 2 applies a dynamic feature selection with genetic algorithm in order to classify unknown attacks and increase the accuracy as well. In current paper, in order to evaluate the performance of the part 1, the modified version of ISCX-2012 and UNSW-N15 datasets with diverse attacks have been used. The performance of the part 1 is compared for two scenarios where UDP DoS is separated from other protocols and where it is not.

In order to evaluate the model robustness and scalability, we will also test the model against five different latest datasets to cover also the new protocols that are missed from ISCX-2012 [START_REF] Sharafaldin | Toward Generating a New Intrusion Detection Dataset and Intrusion Traffic Characterization[END_REF]. Furthermore, for each algorithm, we applied other feature selection methods such as FScore, Chi2 and SVMonline to find the best features [START_REF] Yann | Deep learning[END_REF]. On the other hand, we applied three more different algorithms including MultiLayer Perceptron (MLP), SVM and Decision Tree (DT). The best algorithms were selected through a benchmark on applied datasets and based on the achieved accuracy, FP, FN, training and testing time.

Conclusion

This paper reviewed current mechanisms such as Data Mining (DM) techniques for security purposes and their limitations to defend networks against cyber-attacks. While learning algorithms may have high accuracy in general and longer computation time in comparison to linear algorithms, they may give unexpected responses to a specific type of attack. Therefore, this paper proposed a security platform called Hybrid Anomaly Detection Model (HADM) that uses a combination of linear and learning algorithms along with protocol analyzer. The linear algorithms filter and extract distinctive attributes and features of the cyber-attacks, while the learning algorithms use these attributes and features to identify new types of cyber-attacks. The protocol analyzer classifies and filters vulnerable protocols to avoid unnecessary computation load. The use of linear algorithms in conjunction with learning algorithms allows the HADM to achieve improved efficiency in terms of the accuracy and computation time to detect cyber-attacks over existing solutions. We also described testing scenarios and concluded that the proposed protocol analyzer filters the vulnerable protocols such as UDP and TCP to decrease the computation load, processing time and accuracy for applied algorithms. Our future work concentrates on applying extra datasets, feature selection methods and algorithms to evaluate the model robustness and scalability.

Fig. 3 .

 3 Fig. 3. Dynamic Machine Learning

Fig. 6 .

 6 Fig. 6. Pseudocode for algorithm D

Table 1 .

 1 Features in datasets

	No. Feature	No. Feature	No. Feature
	1	Ethernet size	10	IP destination	19	Connection starting time
	2	Ethernet destination 11	TCP source port	20	IP fragmentation flag
	3	Ethernet source	12	TCP destination port	21	IP fragmentation overlap
	4	IP header length	13	UDP source port	22	TCP ACK flag
	5	IP type of service	14	UDP destination port	23	TCP retransmission
	6	IP length	15	UDP length	24	TCP push flag
	7	IP time to live	16	ICMP type	25	TCP SYN flag
	8	IP protocol	17	ICMP code	26	TCP FIN flag
	9	IP source	18	Duration of connection 27	TCP urgent flag
		Since there are not many variations on features related to protocol, for learning al-
	gorithm I in protocol analyzer module, we considered 9 fixed features including source
	IP address (saddr1, saddr2, saddr3, saddr4), destination IP address (daddr1, daddr2,
	daddr3, daddr4) and time to live (ip.ttl). Three different feature selection methods in-
	cluding Chi2, FScore and SVMonline have been applied on linear algorithm I and II
	and the best combinations for both feature selection methods and algorithms have been
	selected based on the achieved efficiency. The final combinations include FScore for

Table 2 .

 2 Selected features for each algorithm

		Linear Algorithm I (k-NN)		Linear Algorithm II (LR)
	No.	Feature	No.	Feature	No.	Feature	No.	Feature
	1	SDC2	6	dstport	1	daddr4	6	saddr2
	2	daddr2	7	srcport	2	SMC3	7	saddr4
	3	SMC1	8	daddr4	3	ip.len	8	SDC1
	4	saddr2	9	saddr4	4	frame.len	9	daddr2
	5	SMC3	10	ip.ttl	5	daddr3	10	SMC2

Table 3 .

 3 Distribution of packets in dataset

	Data	Normal	DoS	Other attacks	Unknown	Total
	Training (2/3)	1419441	47198	131713	2359518	3957870
	Testing (1/3)	709723	23599	65856	1179763	1978941

Table 4 .

 4 Learning algorithm I performance evaluation

	Data	Accuracy score Cross entropy error	False Negative score Testing time (s)
	ELM 10	0.80	0.84	12.35	0.72
	ELM 50	0.58	3.01	30.95	1.06
	MLP 10	0.87	0.66	00.11	0.09
	MLP 50	0.88	0.57	00.12	0.34

Table 5 .

 5 k-NN and LR detection performance for scenario I

	Input data	Accuracy	Precision	Recall
	k-NN	0.94	0.95	0.93
	LR	0.92	0.95	0.06

Table 6 .

 6 k-NN and LR detection performance for scenario II

	Input data	Accuracy	Precision	Recall
	k-NN	0.99	0.97	0.97
	LR	0.92	0.63	0.20

Table 7 .

 7 Computation time

	Input data	MLP 10	k-NN		LR
			Training	Testing	Training	Testing	Training	Testing
	Scenario I	158.08	0.24	10926.64	5766.36	80.63	0.62
	Scenario II	158.08	0.24	284.63	105.23	80.6	0.44
	5	Discussion on Future Work