## 10 Holistic Guide to OppNets Evaluations  
In each of the previous sections, we have identified the most important insights in take-home messages. Here, we summarize our findings from the trends observed in the OppNet evaluations and further identify few more general properties and challenges in evaluating OppNet protocols. First, and most importantly, performance evaluations have been improving over the last years significantly, with larger and more realistic scenarios being evaluated, and more sophisticated models being applied. Nevertheless, there is room for further improvement. The best practices can be summarized as:  
* Select a standard simulator. We recommend ONE or OMNeT++, as those are the most well documented and actively developed ones. * Select OppNet protocols to compare against. They should be close in their general application scenario (destination-less or destination-oriented, etc.) and should be recent, e.g., from the last five years. Additionally, compare against optimal solutions. This combination ensures the correct positioning of the new protocols into the context of existing ones and how to progress the state of the art. * Design a good application scenario with realistic number of nodes, traffic, cache sizes and simulation time. * Select a good mobility model, able to cater for the application scenario and its scale. Traces (see also the discussion below) or recent hybrid mobility models are a good option. If using traces, use at least 3-5 different traces. Best, use several hybrid models and several traces. * Explore the relevant protocol specific metrics in terms of overhead. * Explore the parameter space of your scenario from minimum to maximum possible values. Report on confidence intervals. Additionally, we would like to summarize our findings in the form of future work suggestions. **Suggestion 1: Open source code. ** The most important and significant improvement is the easiest and the most difficult to enforce at the same time: open source code. If all researchers would publish their code and make it available for other researchers to use and validate, the whole community will profit and the development will speed up significantly. It sounds easy, but there are also counter arguments. Publishing the code means more work to tidy it up, check for errors, comment and make sure it compiles correctly out of your own machine. This is a step which many researchers skip to savetime. Companies are particularly reluctant to share their code, as they believe it would give too many details into possibly patented or copyrighted products, although the probability of actually patenting or bringing the code to market is very low. It is the task of publishers and editors to enforce this development and many communities have started requesting code and other supplementary materials as part of their publication process. **Suggestion 2: Documentation and default parameter values. ** Another important insight is the usage of default parameter values and available models in standard simulators. It is obvious from our discussions that researchers tend to use readily available models and pre-defined values, instead of designing them from scratch and with only quality in mind. This is due to two reasons: First, time restriction is again an issue. Implementing and testing a new model is a time-consuming task and the goals and advantages of doing this are not always obvious. This problem can be easily resolved with Suggestion 1. Second, the complexity of standard simulators and their models can hinder especially less experienced researchers in how to setup them correctly. Here, only a combination of the following can help: rigorous documentation; well-designed default values; design of benchmarking suites; and a lively, helpful community, ready for open discussions. **Suggestion 3: Benchmarks. ** Following from Suggestion 2, the development of benchmarks is highly advisable for the further development of the community.