Review Reports

Round 1

Reviewer 1 Report

The paper presents a P4 implementation of a RINA interior router. The result is important since RINA lacks a high-performance implementation. The authors discuss how this is performed in details, and measure its performance at the end. Finally, an EFCP implementation is compared with an IP one. 

The paper is very well written. Results show the IP implementation has a higher performance. It is good if the authors elaborate on this since the performance difference is not negligible. In addition, some information such as link speed, processing time, and/or measured RTT would be better to be reported.

Author Response

Dear reviewer,

Thanks a lot for your comments!

We are aware that the tests reported in this paper are very preliminary, and use a tool (BMv2) that is not really designed for behaving in a consistent way under load - however, it was the only tool available at the time. The EFCP pipeline carries out more steps than the IP one, hence that could impact the performance as explained in the paper. We have explained that a bit more, and also highlighted that the real performance characteristics of the EFCP pipeline will be evaluated using the Tofino hardware on a real switching platform, we expect that the performance will be equivalent to that of the IP processing pipeline.

The tests reported in the paper have been performed on a single server, using virtual Ethernet links between software-based virtual Ethernet interfaces.

Best regards,

Eduard

Reviewer 2 Report

It is an interesting paper worthy of publication. I have some questions that must be addressed before I can recommend publication

Why was IPv4 and not IPv6 used?

Please address why was a 500-byte packet size chosen instead of a longer packet size, say 1500 bytes? The throughput performance is better at the longer packet length. Is there a hardware limitation involved?

Please briefly describe the DFD elements and their functions in the IRATI Control plane in figure 14 and add them to the acronyms table.

Figure 3 is very similar to Figure 1, V. Maffione, F. Salvestrini, E. Grasa, L. Bergesio and M. Tarzan, "A software development kit to exploit RINA programmability," 2016 IEEE International Conference on Communications (ICC), Kuala Lumpur, 2016, pp. 1-7, doi: 10.1109/ICC.2016.7510711.The two papers have authors in common and Figure 3 should reference the other paper.

There is no discussion on any aspects of security. Please add a paragraph briefly discussing methods/implications for incorporating security protocols. Does the architecture shown in the paper simplify or complicate incorporating security protocols? Is there a recommended set of security protocols already in existence?

Author Response

Dear Reviewer,

Thanks a lot for your comments and feedback! Below we provide some details on how we have addressed your comments and questions:

• "Why was IPv4 and not IPv6 used?" Since this work is a PoC, we just wanted to show that we can implement a pipeline that can process both EFCP and IP packets. We chose IPv4 instead of v6 because it is slightly less work to implement. Adding IPv6 processing requires no conceptual changes, just extending the IP-related parser, deparser and Match-Action modules.
• "Please address why was a 500-byte packet size chosen instead of a longer packet size, say 1500 bytes? The throughput performance is better at the longer packet length. Is there a hardware limitation involved?" Performance has been analyzed for multiple packet sizes (from 250 bytes to 1450 bytes). The 500 bytes packets were chosen to carry out packet-loss vs. inter-arrival time experiments (other packet lengths were also used, with the graph having a very similar shape).
• "Please briefly describe the DFD elements and their functions in the IRATI Control plane in figure 14 and add them to the acronyms table." We have added a short explanation of what the DFD is and their elements within section 6.
• "Figure 3 is very similar to Figure 1, V. Maffione, F. Salvestrini, E. Grasa, L. Bergesio and M. Tarzan, "A software development kit to exploit RINA programmability," 2016 IEEE International Conference on Communications (ICC), Kuala Lumpur, 2016, pp. 1-7, doi: 10.1109/ICC.2016.7510711.The two papers have authors in common and Figure 3 should reference the other paper." We have added the required citation, and adjusted the other reference numbers accordingly.
• "There is no discussion on any aspects of security. Please add a paragraph briefly discussing methods/implications for incorporating security protocols. Does the architecture shown in the paper simplify or complicate incorporating security protocols? Is there a recommended set of security protocols already in existence?" Although security is not the focus of this paper, we have added a short paragraph on section 6.3, with a reference that further ellaborates on it in case interested readers want to know more.

Best regards,

Eduard Grasa

Round 2

Reviewer 2 Report

The author has addressed all of my concerns and I recommend publications