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).
