Re: [LARTC] SFQ buckets/extensions

[don-lartc@isis.cs3-inc.com (Don Cohen)]

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 protos which they
 > carry and TCP with its features to tune becomes a kind of exception.

I don't think this is true.  First, of course, almost all packets TCP.
Second, I'd expect that multiple TCP streams along the same path tend
to equalize, assuming of course that they are not differentiated along
the way.  E.g., with just fifo queuing I'd expect that two scp's along
the same path would tend toward equal bandwidth.  If this is true then 
multiple TCP streams along the same path would tend to act like one.

Perhaps someone else out there can either confirm or debunk that
expectation?
Of course, things get more complicated when the streams have the same
source but different destinations.  In that case I'd expect them to
again adjust to the differences in bandwidth to the different
destinations.  So maybe sub-subqueues below the source IP subqueues
are not so important. 

 > > No, the errors are accumulated.  It's always within one packet of the
 > > ideal in terms of what's sent.  The advantage of measuring queue
 > > length in bytes would be more fairness in dropping, i.e., you should
 > > drop from a queue with 10 packets each of length 1000 bytes instead of
 > > a queue with 20 packets each of length 100 bytes.
 > 
 > 	I didn't get it ? What do you mean - have different queues 
 > agains packets sizes ?

I was suggesting that when you add a packet to a subqueue you not just
record the fact that there are now 16 packets in that subqueue, but
1600 bytes.  Then the limit on total queue size is measured in bytes.
When you enqueue, you check to see whether this packet would cause the
limit to be exceeded, and if so you drop from the subqueue with the
most bytes.

That's closer to the spirit of SFQ, but it's probably more expensive
in run time.  The current implementation has a very fast way to
determine which subqueue has the most packets.  The object is to make
enqueue/dequeue small constant time operations.  I don't see (so far)
how to do that with queue lengths measured in bytes.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/