[Ns-developers] DelayBox - ns-3

[Matt Crinklaw]

On Mon, Mar 24, 2008 at 12:37 PM, Mathieu Lacage
<mathieu.lacage at sophia.inria.fr> wrote:
> hi matt,
>
>
>  > > Hello, I am working with Dr. Weigle on implementing Tmix in ns-3.
>
>  This is great !
>
>  > > as a part of that we were also going to implement delaybox as well.
>
> > >  my 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 done
>
>  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

DelayBox doesn't actually do the packet classification.  Packets are
given a flow id by the TCP Agent (this is the ns-2 equivalent of
ns-3's TCP Socket) which generated them.

>   - 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.

This is right.

>  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).
>

Flow ids (in my mind) are something that should be assigned on a per
connection basis.  Since this is the case, it seems that the most
logical thing to do would be to add functionality to the TCP Socket
code.  This added functionality would allow the code using the socket
to assign a flowid to that socket.  The socket would then assign its
flowid to each packet that it generates.

If you still want to make some general classifier (to be used by any
code which handles a packet) that can classify individual packets, I
have several questions & concerns about how that should work.

>  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'll be working on a DelayBox-only solution for now, where DelayBox is
an extension of NetDevice.
I'll be sure to use the current propagation delay and error models.

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