[LARTC] SFQ improvement ideas

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

I'm glad to see this, since I was planning to make a similar proposal.

 > 1) Backlog depth limit
 > 
 > Currently total limit of SFQ is 128 packets. SFQ tries
 > to keep lengths of all flows to be roughly the same. It
 > means that there can be one flow with 128 packets backlog.
 > 
 > It would be nice to have control over maximal lenght of
 > backlog. To be able to control max delay introduced.

I have an alternative suggestion, which I think might profitably be
added to a number of qdiscs:
 a parameter for the maximum delay allowed for forwarded packets
When you dequeue a packet that is older than that (current time minus
arrival time stamp) you drop it.

This seems trivial to implement and accomplishes the goal much more 
accurately than limiting the size of a flow.  The time a packet spends
in the queue is determined by how many packets arrive for other flows
as well as the length of its own.  The worst case is that it's at the
end of a long flow, say 64 long, and 64 other flows are sending
packets just in time to be served.  So it has to wait for 64 other
packets for each packet ahead of it in its own flow.  And, of course,
to add to the delay, all of the packets involved could be long.

On the other hand a packet that's 128'th in its own queue might only
have to wait for 127 other packets to be sent, and if they're all
short this might not be a long time.

It seems more reasonable to just say don't bother to send any packets
over 5 sec old.

 > 2) Interactive traffic isolation
 > 
 > Cisco IOS implements WFQ which has one queue per flow and
 > common queue for interactive traffic. Packets are queued
 > into interactive queue for some time and after it is clear
 > that they constitute large flow they are assigned private
 > queue. Interactive queue has higher prio.
I was not aware of this distinction between interactive an other.
How do you recognize interactive other than by low rate?
Do you have a pointer to doc?  

 > Nice effect is that short conversations are handled faster
 > and long downloads are isolated with lower priority.
Isn't this just what you get from a queue for each flow?
I thought that's what WFQ did.

 > 3) Hash select
 > 
 > Default SFQ impl. uses src(ip+port)+dst(ip+port) to distinguish
 > connections. It might be useful to be able to set src(ip)+dst(ip)
 > for example (do disallow users to fool SFQ by creating more connections)
 > or src(ip)+dst(ip+port) to make it yet better. I'd suggest tc
 > parameters like "hash " followed by set of "dip,sip,sport,dport,proto"
 > arguments (e.g. ... sfq hash dip sip dport).

I agree (in fact was going to propose exactly this).
The real use I see is that people keep asking for what amounts to hash
only on one address (e.g., fair service to all internal machines).
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/