# Semantic Distributed Data for Vehicular Networks Using the Inter-Planetary File System
## 7 Experimental Results
### Discussion of Results  
The comparison of results has been done against the mechanism proposed by [PERSON] and [PERSON] in [23] named CDVC (content delivery solution based on vehicular cloud) and the address-centric standard [RFC 7094] simulation measurements published in the same research. CDVC takes advantage of name-centric content search and delivery to reduce cost and latency. CDVC and the address-centric standard were simulated using the ns-2 network simulator. IPFS cost and latency values were measured using the real-time docker experiment described before. During the tests, the near-zero default docker end-to-end network delay was increased to match the values provided by the ns-2 simulation. All tests were performed using two different IPFS modes: TCP and QUIC. In these tests, the role of one of the nodes was changed to be a vehicle. The end-to-end delay between the vehicle and the RSUs was configured to 5 ms in both directions. The first batch of tests was realized with the vehicle node initially disconnected from the IPFS network. The first task of the vehicle node was to connect to one of the RSUs. Immediately, it performed one or more content requests. Figure 7: Total of messages exchanged in the peer network when content is added. Once the transaction was finished, the vehicle disconnected from the IPFS network. The results of these tests show that the cost of doing one single content request following this procedure with IPFS is higher than using CDVC or even the address-centric standard. However, the analysis of Figure 8 shows that the number of messages needed to retrieve data follows the equation:  
\[m=m_{0}+r*m_{r} \tag{1}\]  
where the total number of messages (\(m\)) is equal to the fixed amount of messages (\(m_{0}\)) needed to establish a connection to the IPFS network, plus the variable cost of doing each additional content requests (\(r\)). The value of \(m_{r}\) is considerably lower when IPFS is working on QUIC mode, 12 messages per request, versus the 25 messages per request needed when using TCP mode. Therefore, there is a huge improvement using QUIC. However, the fixed cost of the connection is higher with QUIC, 60 messages, versus 40 using TCP. During the tests, the RSU nodes were configured to generate content with an average size of 1000 bytes. The content size does not have any impact in the number of exchanged messages, as long as the maximum message size is lower than the network's maximum transmission unit (MTU), set to the Ethernet standard 1500 bytes during our tests. Otherwise, large messages would need to be fragmented by the network layer. The data format used, CBOR, provides a high compression rate for semantic data,, and therefore, RSUs would rarely need to transmit large content messages to the vehicles. However, the content size does have a direct impact on the number of transmitted bytes. Considering an average size of 1000 bytes per content request, Figure 9 shows that TCP messages had an average size of 109 bytes, while QUIC messages had an average size of 125 bytes. Those numbers actually show that QUIC is more efficient. TCP's average size is smaller because it requires more small protocol-related messages than QUIC. Figure 10 shows that, despite the reduced number of messages and bytes, IPFS needed approximately the same time to process the \(n\) content requests for both connection modes. Without taking into account the time needed to connect and disconnect from the network, with an estimated value of 200 ms, every additional content request needed an average of 20 ms. The reason for this contradictory result is that IPFS is CPU bound: the latency is mostly caused by the time needed by the CPU to process and generate the content. Besides, QUIC is a new transport layer protocol and its CPU usage is not yet as optimized as TCP for Linux operating systems. Figure 8: Total number of messages required to fetch content from another node, including the initial connection.