[Ns-developers] DelayBox - ns-3

[Mathieu Lacage]

hi matt,

> > Hello, I am working with Dr. Weigle on implementing Tmix in ns-3.

This is great !

> >  a part of that we were also going to implement delaybox as well.
> >  plan was to make a subclass of NetDevice that would take the
> >  appropriate actions in the send function.  Is this a good way to go
> >  about it, or is there some other way you would like to see this 

Yes, I understand what you are suggesting and it does indeed sound like
the right approach. There are a couple of comments though so, you might
want to read first the original thread which started this:
http://mailman.isi.edu/pipermail/ns-developers/2008-March/003802.html
and my reply:
http://mailman.isi.edu/pipermail/ns-developers/2008-March/003807.html

To summarize, tom suggested to extend the src/node/simple-net-device
class to implement a DelayBox. I personally don't care that you re-use
this netdevice but you most likely want to use it as a template to start
your own DelayBox implementation

Another important issue which I mentioned in my reply in the original
thread is that while pulling a clone of the ns2 DelayBox is a great
idea, an even better idea would be to try to make some its components
available to other NetDevices and other parts of the system. So, for
example, it seems to me that a DelayBox is something which:
  - takes a packet and classifies it into a flowid
  - takes the flowid, and performs a lookup in a rules table which
contains actions to perform for each packet in the flowid.
  - performs the flowid-specific actions: apply delay, queue, and apply
error model.

Of all the above, we already have code which:
  - applies an error model (src/common/error-model.h)
  - applies a delay (src/devices/wifi/propagation-delay-model.h)

but we clearly miss code which would perform packet classification so, I
suggested to try to build such a generic functionality as part of the
DelayBox work and suggested a simple API (see the email archive I linked
to at the beginning of this email).

We also miss some sort of generic system to apply actions on packets
which belong to a certain flow. I don't really know what this should
look like but, I am sure you could either ignore this part of the
problem and provide a DelayBox-only solution for now, or look at
existing cisco router configuration APIs to get an idea of what such a
thing would look like.

I hope that the above answers some of your questions and I look forward
to hear from you.
Mathieu