[LARTC] New queing discipline

[LARTC] New queing discipline

[Rahul Hari]

I want to implement a new queuing discipline for the tool tc. The new
queuing discipline would support the application of multiple threads
on the same queue with different kinds of traffic. Each kind of packet
will have its own drop probability but while calculating the average
queue length,  the no. of packets in the queue will be equal to the
sum of the individual no. of packets(of the different kinds of
traffic) in the queue.
It would be great if someone could send me names of the files which I
will have to modify and if possible links to any documentation that
might be available for those files.
If this queuing policy already exists, please let me know about its
name and any links that might be helpful in understanding the policy.
Please note that I have tried using GRED, but it does not fulfill my
requirement.
Regards,
Rahul

-- 
Rahul Hari
Junior Under Grad. Student,
Department of CSE,
ITBHU,
Varanasi.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] New queing discipline

[Jonathan Day]

Hmm. Personally, I would not implement a single queue
with multiple algorithms for parsing it. I  can see
all sorts of possible race conditions arising out of
such an approach.

It would seem to be more logical to start by splitting
the traffic into multiple queues, according to the
type of traffic, which you can do with some sort of
classful queueing scheme, such as CBQ. You'd then
process each queue in parallel, using a drop mechanism
specific to that type of traffic.

If you're wanting to differentiate by type of
application, I'd suggest looking at the layer 7
classifier patches.

There are probably QoS schemes that are ideally suited
to what you want, and I'd suggest looking through the
research papers for what has been done so far, and
also to look through the BSD ALTQ code to see what has
been implemented outside of Linux. The usual advice is
to get the most for the least effort, so if someone
has already solved this problem, you would be advised
to build on their solution rather than to reinvent the
wheel.

--- Rahul Hari <rahulhsaxena@gmail.com> wrote:
> I want to implement a new queuing discipline for the
> tool tc. The new
> queuing discipline would support the application of
> multiple threads
> on the same queue with different kinds of traffic.
> Each kind of packet
> will have its own drop probability but while
> calculating the average
> queue length,  the no. of packets in the queue will
> be equal to the
> sum of the individual no. of packets(of the
> different kinds of
> traffic) in the queue.
> It would be great if someone could send me names of
> the files which I
> will have to modify and if possible links to any
> documentation that
> might be available for those files.
> If this queuing policy already exists, please let me
> know about its
> name and any links that might be helpful in
> understanding the policy.
> Please note that I have tried using GRED, but it
> does not fulfill my
> requirement.
> Regards,
> Rahul
> 
> -- 
> Rahul Hari
> Junior Under Grad. Student,
> Department of CSE,
> ITBHU,
> Varanasi.
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
>
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> 


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] New queing discipline

[Rahul Hari]

Sorry for replying a bit too late,
Actually I am not trying to implement a new queuing discipline from
scratch. I am a bit confused about GREDs.
While calculating the Drop probabilities and average queue length,
does GRED take the sum of the no. of packets in all the virtual
queues, or it takes the total no. of packets in each individual queue.
In case it does, the latter, i want to modify the current GRED to
support the former policy.

I am really sorry if this question is really very trivial but, it
would be great if you could tell me if the array char data[0] (being
declared in the struct Qdisc in pkt_sched.h_ is being used in the 
file sch_red.c in the line :

struct red_sched_data *q = (struct red_sched_data *)sch->data;

just for storing an 8 bit data or it has some other use also.

Regards,

Rahul

On 5/16/05, Jonathan Day <imipak@yahoo.com> wrote:
> Hmm. Personally, I would not implement a single queue
> with multiple algorithms for parsing it. I  can see
> all sorts of possible race conditions arising out of
> such an approach.
> 
> It would seem to be more logical to start by splitting
> the traffic into multiple queues, according to the
> type of traffic, which you can do with some sort of
> classful queueing scheme, such as CBQ. You'd then
> process each queue in parallel, using a drop mechanism
> specific to that type of traffic.
> 
> If you're wanting to differentiate by type of
> application, I'd suggest looking at the layer 7
> classifier patches.
> 
> There are probably QoS schemes that are ideally suited
> to what you want, and I'd suggest looking through the
> research papers for what has been done so far, and
> also to look through the BSD ALTQ code to see what has
> been implemented outside of Linux. The usual advice is
> to get the most for the least effort, so if someone
> has already solved this problem, you would be advised
> to build on their solution rather than to reinvent the
> wheel.
> 
> --- Rahul Hari <rahulhsaxena@gmail.com> wrote:
> > I want to implement a new queuing discipline for the
> > tool tc. The new
> > queuing discipline would support the application of
> > multiple threads
> > on the same queue with different kinds of traffic.
> > Each kind of packet
> > will have its own drop probability but while
> > calculating the average
> > queue length,  the no. of packets in the queue will
> > be equal to the
> > sum of the individual no. of packets(of the
> > different kinds of
> > traffic) in the queue.
> > It would be great if someone could send me names of
> > the files which I
> > will have to modify and if possible links to any
> > documentation that
> > might be available for those files.
> > If this queuing policy already exists, please let me
> > know about its
> > name and any links that might be helpful in
> > understanding the policy.
> > Please note that I have tried using GRED, but it
> > does not fulfill my
> > requirement.
> > Regards,
> > Rahul
> >
> > --
> > Rahul Hari
> > Junior Under Grad. Student,
> > Department of CSE,
> > ITBHU,
> > Varanasi.
> > _______________________________________________
> > LARTC mailing list
> > LARTC@mailman.ds9a.nl
> >
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
> >
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
> http://promotions.yahoo.com/new_mail
> 


-- 
Rahul Hari
Junior Under Grad. Student,
Department of CSE,
ITBHU,
Varanasi.
Ph: +91-9845347020
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc