Web browsing performance

The evaluation of the proposed framework in the web browsing scenario consisted on fetching an existing web page (i.e., http://www.ua.pt6_{) deployed in the IP architecture} by NDN and PURSUIT clients. Results are shown in Figure 3.21 and Table 3.4. The former presents the time required to fully load the web page by each client, while the latter presents the signalling size on each network architecture (for a single link). To better assess the impact of the interoperability procedures, values for an IP client are presented as reference values since both client and server supported the same architecture and, therefore, exchanged messages did not required conversion.

From Figure 3.21, it can be observed that when requesting the web page for the first time the delay introduced by the interoperability procedure is higher (approximately 11% for NDN and 17% for PURSUIT) than when compared with subsequent requests. The reason consists on the fact that in the first request the FIXP generates foreign URIs for each resource discovered in the HTML content. In the PURSUIT case, the delay also encompasses the procedures related with the advertising of the identifiers associated with each resource in the PURSUIT Rendezvous Node. If the content does not change, the procedure related with the generation of foreign URI is bypassed in the follow up requests for the same content, being handled as subsequent requests (no cache). However, the delay is still higher than in the current IP approach in approximately 55ms and 14ms for NDN and PURSUIT respectively. Otherwise, if the

6

3.5. Proof-of-concept prototype results 81 0 100 200 300 400 500 600 700

NDN client PURSUIT client IP client

Fetch time (ms)

First request Subsequent requests (no cache) Subsequent requests (cache) IP reference (no conversion)

Figure 3.21: Fetching time to fully load the web page in the web browsing use case content changes, the generation of foreign URIs will only be triggered for unknown resources.

Nevertheless, by enabling the content to be available in the ICN instantiations, in-network caching can be leveraged. In the evaluation scenario, caching capabilities were enabled in Router 1 of the evaluation scenario. Assuming that the web page and associated resources (e.g., CSS and images) are cached in Router 1, clients in the NDN and PURSUIT network architectures were able to load the whole web page, respectively, 4.0 and 3.8 times faster that in the current IP approach. In this case, all resources of the web page were retrieved from the cache in Router 1 and, therefore, requests were not processed by the FIXP. Note that in-network caching is expected in NDN and PURSUIT architectures.

Table 3.4: Signaling overhead on each network architecture (for a single link)

Signaling overhead with ICN as overlay over IP/UDP in bytes (%)

Signaling overhead with ICN over Ethernet in

bytes (%) Exchanged messages C1 NDN IP: 60921 ± 363 (17.3%) NDN: 50124 (14.6%) IP: 60921 ± 363 (17.3%) NDN: 45084 (13.3%) IP: 728 ± 4 NDN: 180 C2 PURSUIT IP: 60539 ± 607 (17.2%) PURSUIT: 30574 (9.4 %) IP: 60539 ± 607 (17.2%) PURSUIT: 23910 (7.5%) IP: 721 ± 8 PURSUIT: 238 C3

In terms of signaling overhead (shown in Table 3.4), an increase of the number of messages in the original network architecture was seen when the request came from NDN and PURSUIT network architectures (and, therefore, requests needed to go through the FIXP) when compared to requests originated in the IP network (and, therefore, not requiring conversion procedures). When interoperability was required, the FIXP created a new TCP connection to fetch each resource of the web page (i.e., no HTTP pipelining) requiring additional TCP control signaling to establish and terminate each connection, while the client in the IP network architecture was able to reuse the same TCP connection to request several resources.

Still, even if more messages were exchanged in the original network when the interoperability occurred, the signalling overhead was smaller. The HTTP GET messages issued by the FIXP contained only the minimal required information (i.e., Host and Accept HTTP headers) to request the desired content, representing approximately less 250-300 bytes per resource request comparing with the IP-only approach. Moreover, the number of exchanged messages and the related signalling overhead in the ICN network architectures was less than the one verified in the IP network architecture.

In Figure 3.22, the delay introduced by the FIXP is detailed for each step of the message conversion for different types of content.

0 10 20 30 40 50 60 70 80 90 HTML PURSUIT HTML NDN JPG PURSUIT JPG NDN CSS PURSUIT CSS NDN Processing time (ms)

Handle ICN Request FIXP Processing ICN Request Creating and send HTTP Request Handle HTTP Response FIXP Processing HTTP Response Create and send ICN Response

Figure 3.22: Detailed FIXP delay. File sizes: (i) HTML file = 30.7kB; (ii) JPG file = 7.4kB; (iii) CSS file = 30.3kB

3.5. Proof-of-concept prototype results 83 the request message has been found to be less time consuming than the correspondent response message. The reason resides on the fact that converting NDN/PURSUIT requests into a HTTP-compatible request is a straight forward process, consisting on finding the mapping of the foreign URI and creating the correspondent HTTP GET message. In turn, the conversion of the HTTP response message into NDN/PURSUIT compatible messages proved to be a more complex process where (i) content is converted if required (e.g. HTML contents) to be in compliance with the destination network architecture (as verified for the HTML content in Figure 3.22, represented in “FIXP Processing HTTP Response” step) ; and (ii) content is split in several chunks which are sent in separated messages.

In the case of NDN, since the signature for each NDN Data message is calculated and then included in the message itself, the delay associated to the creation and sending of the ICN response messages is higher in NDN than in the PURSUIT case (as verified for all types of content in Figure 3.22, represented in “Create and send ICN Response” step). In addition, in the NDN case, the greater the content size, the higher is the number of NDN Data messages that need to be sent (since the content is split in more chunks) and, therefore, the higher the time to create and send all the NDN messages (as verified when comparing the “Create and send ICN Response” step in Figure 3.22 of NDN for e.g. the JPG and CSS content types of content).

Finally, whenever contents needed to be adapted to be compatible with the destination network architecture, this step (represented in Figure 3.22 as “FIXP Processing HTTP Response”) demonstrated to be the most time consuming in prototype implementation. Notwithstanding, adapting the contents is not required for all types of content (as observed for the JPG and CSS files), which significantly reduces the processing time of the response messages in the FIXP.