[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[altq 501] Re: Message for altq





> -----Original Message-----
> From: owner-altq@csl.sony.co.jp [mailto:owner-altq@csl.sony.co.jp]On
> Behalf Of Kenjiro Cho
> Sent: Wednesday, August 09, 2000 07:37
> To: altq@csl.sony.co.jp; uhl@mamba.gsfc.nasa.gov
> Subject: [altq 500] Re: Message for altq
>
>
>
> An alternative approach:
>    when a queue with a filter (and weight) is specified,
>    create a new queue in addition to the existing queues.
>    unmatched packets are hashed into one of the original queues.
>
> A problem is that weight doesn't tell how much bandwidth it will
> receive.  Suppose you set 200% weight to a queue for a 10Mbps link.
> When there's only one competing flow, it gets 6.6Mbps.
> When there's 8 competing flows, it gets 2Mbps.
> Is this behavior really what you want?

not really.
I want to guarantee a specified bandwidth. That should be allowed only on my
(new) queues.

	fulvio


> It seems to me that it is more useful to have WFQ-style round-robin
> scheduling within the default class of CBQ or HFSC.
>
> -Kenjiro
>
> George Uhl wrote:
> > Yes, this is my preference as well.  The issue becomes
> > what weight to assign to the non-filter-matching traffic
> > queues.  The normal settings (wt = 100) are good default
> > values, but the default weights should also be user
> > configurable.
> >
> > George
> >
> > > My preference goes to:
> > >
> > > - allowing an option "default" that makes WFQ using the
> normal settings
> > > (packets are hashed into one of the queues)
> > >
> > > - inserting a "filtering" specification (like CBQ and HFSC)
> in order to
> > > customize the way flows are assigned to each queue.
> > >
> > > Just an idea.
> > > Cheers,
> > >
> > > 	fulvio
>
>