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 toss
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 size
- 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 subqueues.
And, of course, one could have
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 without
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
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
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 only
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
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
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 full sfq have to
... What if SFQ were to start with a minimal number of buckets, and
track how 'deep' each bucket was, then go to a larger number of bits
(2/4 at a time?) if the buckets hit a certain depth? Theoretically,
this would mean that 'fairness' would be achieved more often in current
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 to take
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
13 matches
Mail list logo
