Rethinking QOS Classification

Discussion in 'Tomato Firmware' started by Planiwa, Jun 16, 2013.

  1. Planiwa

    Planiwa Network Guru Member

    There are two aspects to this:

    1. Updating the rules to classify (newer) traffic types.

    2. Updating the categories to reflect (newer) reality patterns.

    Here are some examples:

    1. Updating the rules to (correctly) classify (newer) traffic types.

    1.1 Amazon AWS (amazonaws), port 4244 and others.
    1.2 Ports 12350, 400xx -- whatever?
    1.3 L7 errors -- false "skype-out"

    2. Updating the categories to reflect (newer) reality patterns.

    2.1 Which is the correct "priority" category for Cloud services, etc?
    2.2 Should Skype be classified as "malware" rather than "VOIP/Game"?
    2.3 Is it sensible to classify games that are well-behaved and *Voice* over IP in the same category as massively parallel P2P games and abusive P2P apps such as Skype, especially HD *Video* (conference) "calls", that take far more resources than "Media" or "Download"?
  2. cloneman

    cloneman Addicted to LI Member

    My thoughts on this is that less is more, I don't use other people's classification rules (thought I don't manage a network with many users).

    In general my approach is to assign a low maximum to high priority classes. Meaning, if a high priority application misbehaves, we assume its broken and don't let it steal too much traffic. In this manner, classes with a large scope become "best effort" and fall apart when something is cheating (but without affecting other classes).

    A workaround for this is to create secondary rules to classify the same traffic, ones which are least likely to be subject to classifications or abuse.

    Example: you set an rule for Skype that is high on the list but limits upstream bandwidth to 2mbit out of 3mbit.
    & You set a seperate rule for SIP traffic with a ~400kbit minimum to allow for a few voip calls to run perfectly even if the skype class is congested...

    Alternatively, services that occasionally need large amounts of bandwidth, but also benefit from low latency most of the time, you can bury at the bottom, with a higher (~10%) min and high maximum (90-100%). This means the app will have great response time , all the time, unless the overall network is congested AND it is asking for lots of bandwidth.
  3. Planiwa

    Planiwa Network Guru Member

    Apple iCloud uses Microsoft Windows-Azure-Blob Cloud Services!


    Skype may use much, much, more bandwidth than it needs for the actual call. When it sees lots of bandwidth, it will turn the Tomato router into a "Supernode", i.e. a Skype-run connection-server operating as part of its own P2P network!

    L7 may falsely identify innocent traffic as Skypeout. Conversely, it may false identify even more reckless traffic than Skype as Skypeout.

    Giving Skype a lot of bandwidth with the intention of seeing how much it takes and assuming that's how much it needs may result in very nasty surprises.

    Skype says: "Don't worry about Skype using lots of connections"! That is worrisome.
    How can we distinguish Skype from other reckless aggressive P2P apps?
  4. Elfew

    Elfew Network Guru Member

    OK, you can start with rewriting rules... I think it is useles, I dont use them...

    I dont know why you dont like skype... unlimited bandwith, fast internet for low price... so dont use skype and be happy.

    My opinion - rules are outdated but it is not important to rewrite them, because nobody uses them... there are many features with higher priority
  5. Monk E. Boy

    Monk E. Boy Network Guru Member

    I don't hate or love Skype, I just don't like that the thing has morphed into what amounts to a P2P application. At $10000 per infringement attempt I can't allow P2P, period, which means I can't allow Skype.

    It needs to work like every over chat program on the face of the planet and use fixed ports. They use fixed ports so you can easily classify the traffic and get it on its way with a minimum of delay. Demanding that everyone use deep packet inspection to classify real-time video traffic is ridiculously absurd and, frankly, inexcusable.
  6. Planiwa

    Planiwa Network Guru Member

    (There is a thread specific to the question of Skype and alternatives:
    "Admin Perspective: Skype vs. Hangouts")

    Yes, indeed, Skype uses whatever ports it thinks it can get away with, including 80, 443, 993.
    And yes, L7 is absurd and ineffective.

    Unfortunately I manage networks made up, in part, of academic researchers who need to confer regularly with colleagues around the world, and all they know is Skype!

    Their need is legitimate, and I cannot (at this point) offer them an alternative that is within their grasp. (see the thread mentioned above).

    So, I try to do what is possible under the circumstances. Such is the nature of problem solving.

    The situation is complicated by:

    1. There is plenty of bandwidth to accommodate multiple Skype HD video sessions, even conference sessions.

    2. If I misclassify Skype connections as reckless P2P and stomp on them, this will hurt innocent, legitimate persons, who have scheduled a meeting, perhaps getting up earlier or staying up later, than usual, because of time-zone differences.

    3. If I misclassify reckless P2P as Skype, this will cause connection congestion, resulting in unacceptable latency, making Skype sessions impossible, and again hurting innocent legitimate persons, both Skype users and others.

    4. There actually are users who use P2P apps (data or games) responsibly. But others are oblivious to what they are doing and incapable of self-regulation.

    5. Some Skype clients (OSX, Windows?) can be configured to use a particular port, but others (iOS) can't be. It may be practical to ask users to configure their clients to use a particular port.

    Unfortunately I have heard nothing from people who have actually solved the problem!

    My best alternative to trying to make QOS work with P2P (which includes Skype), is to severely limit those users who have shown themselves incorrigibly reckless in the past, through BW limits and UDP limits.

    And, of course, minimizing UDP timeouts.

    Still, the "Cloud" connections are a concern. Few QOS admins seem to have given much thought to their impact and classification.

    Still, no one here has identified ports: 12350 and 400xx.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice