On Fri, Jun 07, 2002 at 04:37:07PM +0200, Jan Coppens wrote:
> Why not implementing the sfb (stochastic fair Blue)? From the papers I read,
> the algorithm with the double buffered moving hash extension, seemed like a
> better alternative for the FRED, Stochastic fair RED and SFQ.
I'd like to tos
For the sake of a play-by-play (and why it wouldn't quite work right
initially):
1) we need to dequeue a packet
2) we ask the 11 bit lower SFC for a packet.
3) it asks the upper SFC
4) the upper SFC takes the next bucket, based on IP, and gives us a
packet.
5) the lower SFC takes that packet and
It can't be done. Outer SFC could do nothing with the packet.
It could only give it to inner one
On Fri, 7 Jun 2002, Michael T. Babcock wrote:
> > exactly. The discussion should be about how to implement if
> > efficiently. What about to have N IP buckets and N IP/PORT
> > buckets. When IP/P
> exactly. The discussion should be about how to implement if
> efficiently. What about to have N IP buckets and N IP/PORT
> buckets. When IP/PORT hash resolves to bucket then we could
> (re)link the
Consider a new classful queueing discipline "SFC" that behaves exactly
as SFQ does and can have
> that quite possible ... The only way to equalize bandwidth "fairly" in
> these scenarios still seems to be to implement the hierarchial approach
> of hashing against destination IP (the user receiving the packets) and
exactly. The discussion should be about how to implement if
efficiently. What
> No, i do not think like this. If we think just for TCP connections
> we may end up with ideas like changig window size. TCP tunes to send this
> way but it also tries to send more each 5 seconds, if it have data.
please not this. :-) Packetizer sw goes this way and it is
- not allowed by
Alexander Atanasov writes:
> SFQ classify connections with ports, esfq classify them and just by IP so
> we can have flows:
> SRC IP+proto+DST IP+PORT - one flow
> just DST IP - one flow
> another we can think of - one flow
> So i think just about packets of size bytes but wi
- Original Message -
From: "Michael T. Babcock" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 07, 2002 4:18 PM
Subject: RE: [LARTC] SFQ buckets/extensions
> > In a long term always droping from the largest subqueue
> > gives you equal
> In a long term always droping from the largest subqueue
> gives you equal subqueues.
And, of course, one could have it drop them using a RED-like algorithm
to make the sessions stabilize themselves better.
> what they have) is better. May be doing it like the cbq with average
> packet s
On Thu, 6 Jun 2002, Don Cohen wrote:
> Maybe you think it's just incredibly lucky that these sources are
> both sending at just the same rate that they're being served, but
> that's what tcp is supposed to do.
No, i do not think like this. If we think just for TCP connections
we may en
Alexander Atanasov writes:
> > Again, no. It's perfectly possible for one queue to always have
> > length in range 99-101 and another to always have length 9-11 and
> > still be serving them both at the same rate. Just imagine that one
> > client sends 100 packets at once and the other sends
On Thu, 6 Jun 2002, Don Cohen wrote:
> Alexander Atanasov writes:
>
> > > I don't see why that should be the case. And I don't recall ever
> > > observing it. This adaptation time should be practically zero.
> > > There's no work in making the queues equal.
> >
> >When queues get ful
Alexander Atanasov writes:
> > I don't see why that should be the case. And I don't recall ever
> > observing it. This adaptation time should be practically zero.
> > There's no work in making the queues equal.
>
> When queues get full sfq have to drop packets and it must
> send les
On Wed, 5 Jun 2002, Don Cohen wrote:
> Alexander Atanasov writes:
> > > > Plaing with it gives interesting results:
> > > > higher depth -> makes flows equal slower
> > > > small depth -> makes flows equal faster
> > > > limit kills big delays when set at about
> I disagree that the goal is to make the subqueues the same length.
> The goal is to serve them with the same bandwidth (as long as they
> don't become empty.)
Not that you need backing-up, but I agree with you. SFQ is there to provide
near-fair queuing on a per-session basis. As modified, it
Alexander Atanasov writes:
> At first look - i think i've have to incorporate my changes into
> your work. I've not done much just added hashes and unlocked what
> Alexey Kuznetsov did.
Not quite that simple. You have to throw out about half of my file,
mostly the last third or so, which
On Wed, 5 Jun 2002, Don Cohen wrote:
> extensions
> > And all the discussions tend to lead to the conclusion that there should
> > be an sfq option (when the queue is created) for:
> >a) how big the hash is
> >b) whether to take into account source ports or not
> >c) whether
17 matches
Mail list logo
