Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 2920 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Traffic prioritization observations

PowderHound
Hi all,

It seems a number of people on this forum are having issues with traffic prioritization.  I've been using ASG for about a week and had similar questions/issues.

For the benefit of others, here is a short summary of what I have observed, and which doesn't seem to be fully explained in the documentation.

First, bandwidth guarantees and limits relate only to traffic outbound from the ASG.  So, if you want to restrict HTTP traffic for web browsing, place the limit on the internal interface (you may also want to put a smaller restriction on the external interface to limit HTTP requests but they would be small by comparison).

The Guaranteed Bandwidth field has a misleading name, as it does not always guarantee the stated amount of bandwidth.  My key observation is that bandwidth is not managed completely dynamically.  It appears to be managed only at the point when TCP sessions are initially created (I haven't checked to see how this applies to non-TCP traffic).

Say, for example, that I wish to set a guaranteed bandwidth for SIP (VoIP) traffic so that my web downloads don't fully utilize my circuit and prevent me from making/receiving calls.  I want to guarantee, say, 50kbit/s in each direction for SIP.  So, I set up bandwidth pools for the SIP protocol on both external and internal interfaces, setting bandwidth to 50kbit/s on each.

Then, I go ahead and start a big HTTP download and expect that 50kbit/s would be available to my VoIP phone.  Wrong.  The circuit is fully utilized.

The reason seems to be that the ASG only guarantees 50kbit/s to SIP once the SIP session has started and if enough spare bandwidth exists at that time.

So, with the same configuration, if I start my phone call before my HTTP transfer then the SIP session will have it's 50kbit/s guaranteed and the HTTP session won't cut into it.

Back to the first scenario, where the HTTP download is started first, when the download ends, assuming the (crippled) SIP session is still open, bandwidth becomes available for SIP once again.  If I then start a second download, 50kbit/s will be reserved for SIP because the SIP session started first.

In other words, you cannot use QoS on the ASG for full traffic prioritization.  It works on a session-by-session basis rather than a packet-by-packet basis.  This works fine if all your traffic has short, bursty sessions (or, presumably, is not session based such as UDP).  However, if you have long-running high bandwidth sessions such as HTTP downloads then using guaranteed bandwidth settings are not enough.

In this example, I had to set a maximum bandwidth limitation on HTTP downloads (internal interface) so that if the download starts before the SIP session then it won't use more than its allocated maximum.  This has two flaws.  First, I limit my bandwidth unnecessarily when there is no SIP session open.  Second, how do I adequately restrict all possible protocols?  I can't just use my available bandwidth and subtract 50kbit/s.  If I did, then another protocol (eg FTP) could use up that 50kbit/s.  So, I have to limit all protocols (or all destinations other than my SIP server).  But what limit do I choose?  If HTTP is already using all but 50kbit/s then nothing is left and I'd have to use zero.  So, I have to set my limits lower still and make a best guess for what protocols might be used at the same time and what bandwidth they will need.

So, traffic prioritization can be achieved - sort of.  But only at the expense of limiting your bandwidth at all times to other traffic.  And then, there is still no guarantee.  It is a bandwidth reservation system, not a traffic prioritization system.

I hope this helps clarify QoS for others out there.  Let me know if you disagree with the above, or have other suggestions for prioritization - I'm only a recent user of the ASG.


This thread was automatically locked due to age.
Parents
  • 0
    Excellent presentation.

    You can have limitations on HTTP and FTP together by combining the services in a single group for the 'Traffic Selector' definition.  Or, for example, if you have a 5MB feed, you could guarantee each 1MB and limit each to 3MB, but that wouldn't limit their total bandwidth usage.

    I chronicled another situation here a few weeks ago.  A client's in-house FTP server was being accessed by a service provider, and the upload from the FTP server was drowning the regular small HTTP requests from the in-house users.  The customer had set QoS on the internal interface in an attempt to guarantee bandwidth to the users, but that didn't work.  I simply set QoS on the External interface to guarantee about 100kb for surf requests to go out, and the complaints ceased.
  • 0 in reply to BAlfson
    So, I should simply make a group that includes all protocols that I use and limit that group.  That should work, I think, and with only a relatively small penalty to bandwidth.

    On your example, I guess the only hitch there is that if there were no open HTTP sessions when the FTP starts then the bandwidth would all get hogged by the FTP despite the reservation you added.  However, the likelihood of there being no open HTTP sessions in even a moderately sized organization is low, so there is a good chance that it will be okay most of the time.

    In a low use environment, it might be possible to fool the ASG into thinking there is a session open by initiating a dummy HTTP session.  It would be interesting to know how a session is deemed ended (eg. timeout on receiving a return packet).  As a work-around, you could set up a "TCP ping" to keep the reservation active if you needed to.  This would be relatively simple to script.
  • 0 in reply to PowderHound
    I don't think you can use the same service-port in more than one band-width pool.  In other words, if a port is in pool 1, the Astaro never checks pool 2 for that service-port.

    PS Of course, that's assuming the same Source and Destination in the Traffic Source.
Reply
  • 0 in reply to PowderHound
    I don't think you can use the same service-port in more than one band-width pool.  In other words, if a port is in pool 1, the Astaro never checks pool 2 for that service-port.

    PS Of course, that's assuming the same Source and Destination in the Traffic Source.
Children
No Data