cls_flow Flow Classifier

This topic contains 1 reply, has 0 voices, and was last updated by  AtroposX 8 years, 2 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #42777

    AtroposX
    Member

    Has anyone used this module, “cls_flow”?

    http://www.shorewall.net/manpages6/shorewall6-tcclasses.html

    This states it may be able to classify a flow by srcip or dstip. Which would be good for congestion of bittorrent users. With just regular sfq on a class, a flow would be classified as one connection. With bittorrent, one ip, could have multiple connections, not balancing properly.

    If cls_flow could be used and classifying a flow as by just a srcip or dstip, one can balance a link more efficiently, especially when using voip on a link with p2p running.

    lsmod lists it as loaded, but when using “tc filter add flow help” states “Unknown filter “flow”, hence option help is unparsable”.

    It looks like it is enabled in the Zeroshell Kernel though, under Networking options…….., QoS / Fair Queuing.

    #51429

    AtroposX
    Member

    http://oneitguy.com/blogs/netprince/fair-traffic-sharing-esfq-broken-switching-sfqexternal-classifiers

    From some reading esfq is really used any more, only sfq is. Sfq allocates bandwidth in a class evenly amongst individual connections, the default linux way.

    This script implements esfq’s support by using sfq with an external classifier.

    An example of using this method, a class of 5megs download, with only two people using it, one person with 4 connections active, say 4 ftp download sessions, and the other person only has 1 ftp session active, the class will be evenly distributed amongst 5, so 1meg per the 5 connections.

    Which is correct for the way sfq works, but is not “fair” to a human sense. It should be based on src/dst.

    If the cls_flow module could be implemented, and state flow hash keys dst, then the bandwidth will be distributed based on the dst ip rather than by single connections, evenly distributing the bandwidth into 2 of 2.5megs each per person, resulting in fairness.

    When more people get put into the class, say 8 more, making a total of 10 people, the 5meg class gets divided by 10, and turns into 512k per person, until the person stops talking, then that 512k goes back into the class for the others to use, and dynamically changes as needed.

    In beta 14 you can do “modprobe cls_flow” and it shows up in lsmod as loaded, but when using the command of “tc filter add flow help” to get qa basic flow help, you get “Unknown filter “flow”, hence option “help” is unparsable. Perhaps it needs to be loaded in a preboot script, prior to QoS loading?

    Any help would be appreciated, as this would make distributing bandwidth in a class much more efficient and fair. Too many people using p2p in a class with just basic sfq would ruin a class because of all of the connections it builds up, making the class useless for the other people. If based on cls_flow, all people would get their divided share fairly, and evenly.

    #51430

    AtroposX
    Member

    http://fatooh.org/esfq-2.6/current/README

    Here is some documentation on this patching the kernel for support on this. Calls for replacing all calls of the original tc utility in any scripts that call for it, with the newly-patched tc-esfq version. This would be such a nice addition please, or any feedback/comments.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.