Re: [LARTC] SFQ buckets/extensions

[Alexander Atanasov <alex@ssi.bg>]

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 75-85% of depth.
>  > > 
>  > > I don't understand what these last three lines mean.  Could you
>  > > explain?
>  > 
>  > 	depth is how much packets which are queued on a row of the
>  > hash table. If you have large queues (higher depth) sfq reacts slower when
>  > a new flow appears (it has to do more work to make queue lengths equal
>  > ). When you have short queues it reacts faster, so adjusting depth
>  > to your bandwidth and traffic type can make it do better work.
>  > I set bounded cbq class 320kbits and esfq with dst hash:
>  > 	Start an upload - it gets 40KB
>  > 	Start second one - it should get 20KB asap to be fair.
>  > With depth 128 it would take it let's say 6 sec. to make both 20KB, with
>  > depth 64 about 3sec - drop packets early with shorter queue.
>  > (i've to make some exact measurements since this is just an example
>  > and may not be correct). 
> 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 less(delay) or drop on the faster flows which gets a bigger queues to
slow down them. That's the work i mean. And it really depends on the
subflow depth.

> (Let's use the word queue to mean the whole SFQ and subqueue for the
> part sharing a hash index.)
> If you have, say, 100 packets in one subqueue and 10 in another they're
> already sharing the bandwidth 50-50. 

	No, that means that the flow with 100 packets is using about
10 times more bandwidth. To be fair both must have lenght around 50.

> 
>  > 	limit sets a threshold on queued packets - if a packet exceeds
>  > it's dropped so delay is smaller, but when it tries to make flows equal it
>  > counts depth, not limit. With above example depth 128 and limit 100:
>  > 	When first upload enqueue 100 packets sfq starts to drop,
>  > but goal to make flows equal is 64 packets in queue. Flow doesn't get
>  > the 28 packets which are to be enqueued and delayed for a long time and
>  > probably dropped when recived.
> 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.)

	I agree that the goal is to serve the same bandwidth, but
bandwidth is served with packets which carry a data of X bytes up to MTU,
so i consider packets as the base unit. ( look at the example as both ftp 
flows send the same sized packets with the same data at the same rate).  
You have:
	enqueue -> put in the subflow   - len++
	dequeue -> get from the subflow - len--

So when dequeues ocure slower than enqueues they fill up - packets
are delayed and at some point get dropped. So the problem is when
your queues get full with packets - how to dequeue to be fair to flows
which are identified with the hash. SFQ tries to make equal queues for the
flows to do this.

> Queue length depends on how many packets each download is willing to
> send without an ack.  If one is willing to send 100 and the other is
> willing to send 10, then the subqueues will likely be length 100 and
> 10, but each will still get the same bandwidth.  Without window

	That's true if you can send 110 packets and not exceed your
bandwidth , trouble comes when you can send 100 , how to deal with with
the 10 that exceed. 

> scaling the max window size is 64K which is only about 45 packets,
> so it's not really normal to have 100 packets in a subqueue.

	It's normal if you have congested links, it's not good
in anyway :( But that's why qos is to avoid and handle this.
You have 45 packets per one flow but with 3 hash collisions you get above
the 128 packets limit and drop. esfq sloves this you can tune
number of subflows and their lengths.

-- 
have fun,
alex


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/