Delfoi

[pberndt]

Hello,

I have implemented a global Internet delay model that I would like to contribute to the master branch:

The DELFOI (Delay Estimation Localized For Omnet++/Inet) model implements
end-to-end Internet delay including

• node specific access network delay
• node specific access bandwidths
• Global Network Positioning (GNP) estimates of node to node minimum backbone delay
• region-to-region specific jitter

The model usually is parametrized from user measurements obtained through the
website www.speedtest.net. With the parametrization file installed, it is
very easy to use (see example).

The parametrization for each node is sampled from the group (e.g. "US") specified
as Par or property.

More info:

• Berndt, P., Battré, D. and Kao, O. "A Hybrid Approach to Modeling End-to-End
  Delay in P2P Networks"'Proceedings of the Workshop on Advanced Video
  Streaming Techniques for Peer-to-Peer Networks and Social Networking', ACM
  Press, 2010.
• Berndt, P., Raack, M. and Kao, O. "Spanning a Global Delay Model from
  HTTP-Measurements"'Proc of the Annual International Conference on Network
  Technologies & Communications (NTC 2010)', Global Science and Technology Forum
  (GSTF), 2010, pp. N77-N82.
• Example: examples/inet/gnpping

Requirements:

• gnplib
  https://sourceforge.net/projects/gnplib/

• Parametrization data:
  speedtest.net datasets may be obtained from Ookla
  http://www.speedtest.net/contact.php
  Three days worth of measurement data ought to suffice.

  Automated scripts to generate parametrization data ("measured_data.xml") from
  speedtest.net measurements are included with gnplib
  in the vibello directory.

  Alternatively, an XML data set (though without access delay!) can be
  obtained from
  http://peerfact.kom.e-technik.tu-darmstadt.de/de/downloads/

Best Regards,
Philipp

[rhornig]

Thanks, I have pulled this to the topic/delphoi branch. We will merge it with the integration branch soon. i see you have added a DatarateChannel2 which seems to be some kind of fix for the original channel. What was the bug that it is supposed to fix?

[pberndt]

Thanks, the problem with the original DatarateChannel is that calling any of the setters has no effect without calling the protected method rereadPars() afterwards. Please let me know if there is another way to accomplish this. I noticed there is a method handleParameterChange(..) but that is protected, too. Therefore, I subclassed DatarateChannel and call rereadPars() in each setter. This works okay for Delfoi. However, if channel parameters change a lot DatarateChannel should be optimized by re-reading just the par that was actually changed.

[rhornig]

Hello, this was a reported issue with OMNeT 4.0 if you set the paramaters at initialization time:
http://dev.omnetpp.org/bugs/view.php?id=109

it was fixed for 4.1 so my question is, have you experienced the problem with 4.0 or 4.1? A suppose you are setting the pars at init state from some modules. If it is a problem with 4.1 then we should further investigate, becaus in that case this as a bug in OMNeT kernel.

I have checked your code and it seems that you are setting the delay and datarate params in stage 2 which should work with 4.1 because handleParameterChange is called in 4.1 IF the owner component (channel) is already in initialized state. The channels are initialized in stage 0 so you should be fine without the DataChannel2 workaround.

[pberndt]

Oh yes, that was a 4.0 thing that seems to be fixed with 4.1. Since 4.1 was released quite a while ago, I now made it a requirement for Delfoi and removed the work-around. When compiling with OMNeT++ version < 4.1 it will now print a compile time warning and throws a runtime error when trying to run a delfoi model.

[rhornig]

Okay, great. I will look into how to integrate it in the following days. I will close this pull request once it is successfully merged.