[Ns-developers] DelayBox - ns-3
Tom Henderson
tomh at tomh.org
Mon Apr 7 09:24:59 PDT 2008
>-----Original Message-----
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Monday, April 7, 2008 07:58 AM
>To: 'Matt Crinklaw'
>Cc: 'ns-developers'
>Subject: Re: [Ns-developers] DelayBox - ns-3
>
>
>On Sat, 2008-04-05 at 16:17 -0400, Matt Crinklaw wrote:
>
>> 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.
>
>Ok. Thanks for the precision.
>
>> 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.
>
>I think that it would be nice to avoid adding cruft to the socket code
>and to leave this to the application generating traffic or to move this
>in some more generic packet classification facility.
I recommend looking at netfilter conntrack facility for Linux. We talked earlier about adding support for common netfilter hooks in the kernel. Some kind of stateful conntracking object might be (optionally) aggregated to such a hook.
A quick and dirty option would be to add an optional packet tagger to ns3::Socket. It could be enabled similar to how Packet metadata is enabled. That might be appropriate to make progress on DelayBox without getting distracted immediately by building a general conntrack/netfilter facility.
Tom
More information about the Ns-developers
mailing list