useful description of QoS anywhere?

I think the limitation to a session basis is because of the way the world's webservers work.  If you also enable QoS on the External interface, the inbound traffic on it is then managed by "various techniques such as Stochastic Fairness Queuing (SFQ) or Random Early Detection (RED)."

In any case, the Astaro QoS focuses on guaranteeing bandwidth to specific traffic, and is not organized around limiting other traffic.  That, in general, allows maximal usage of bandwidth instead of artificially limiting some traffic when it's unnecessary.  There's another thread that was active yesterday with a number for a KB article about guaranteeing bandwidth to an IPsec VPN.

Currently I use "Any -> HTTP Proxy -> Any".

I don't think there should be any port 8080 traffic back to internal IPs from the Internal interface, and I would have expected the rule to apply to traffic coming from the internal interface.  If you were to keep that, then, instead of the first "Any," I think you would want "Internet" which is included in V7.5, but needs to be defined in earlier versions: 0.0.0.0/0 bound to External interface.

Even those of us who charge for helping people with Astaro need better documentation.  That's one of the reasons I've been so active here over the last year - pushing and proding others to document and then attempting to repeat and summarize to be sure I've understood correctly.

Little by little, the stuff on here gets into the KnowledgeBase.  I keep pushing Astaro to adopt the Amazon.com model* for handling support requests, but the light hasn't gone on yet.

Cheers - Bob
* Treat each request as a request to improve the programs and/or documentation.

I think the limitation to a session basis is because of the way the world's webservers work.  If you also enable QoS on the External interface, the inbound traffic on it is then managed by "various techniques such as Stochastic Fairness Queuing (SFQ) or Random Early Detection (RED)."

In any case, the Astaro QoS focuses on guaranteeing bandwidth to specific traffic, and is not organized around limiting other traffic.  That, in general, allows maximal usage of bandwidth instead of artificially limiting some traffic when it's unnecessary.  There's another thread that was active yesterday with a number for a KB article about guaranteeing bandwidth to an IPsec VPN.

Currently I use "Any -> HTTP Proxy -> Any".

I don't think there should be any port 8080 traffic back to internal IPs from the Internal interface, and I would have expected the rule to apply to traffic coming from the internal interface.  If you were to keep that, then, instead of the first "Any," I think you would want "Internet" which is included in V7.5, but needs to be defined in earlier versions: 0.0.0.0/0 bound to External interface.

Even those of us who charge for helping people with Astaro need better documentation.  That's one of the reasons I've been so active here over the last year - pushing and proding others to document and then attempting to repeat and summarize to be sure I've understood correctly.

Little by little, the stuff on here gets into the KnowledgeBase.  I keep pushing Astaro to adopt the Amazon.com model* for handling support requests, but the light hasn't gone on yet.

Cheers - Bob
* Treat each request as a request to improve the programs and/or documentation.

I don't think there should be any port 8080 traffic back to internal IPs from the Internal interface, and I would have expected the rule to apply to traffic coming from the internal interface.  If you were to keep that, then, instead of the first "Any," I think you would want "Internet" which is included in V7.5, but needs to be defined in earlier versions: 0.0.0.0/0 bound to External interface.

After upgrading to v7.500, I have changed the traffic selector from "Any -> HTTP Proxy -> Any" to "Internet -> HTTP Proxy -> Any", but with no success. Downloads are still consuming the complete bandwidth. 

And taking a look into the traffic with Ethereal shows that the packets are coming from :8080 to :.

How is the service specification of a traffic selector meant? The port of the selected service is considered to be the target port, no matter on which interface the selector is bound later on? In this case it would be clear that my selector can not work, because the traffic is *coming* from that port (8080), not *going* to that port.


Another question: I've created traffic selectors and bandwidth rules to guarantee bandwidth for one VPN tunnel. Hopefully it works, but so far I can not easily check this (one of my problems with Astaro's BW management). Would it make sense to use the TOS-Bits "minimize delay" in these traffic selectors?

Bye, Frank

At which time of data transfer the traffic selectors are checked

at the time a packet ENTERS an interface and also when it LEAVES the ASG on an interface

what are the source and destination from QoS's perspective? 

source = the sender of the packet, destination = the recipient of the packet

On which interface(s) do I have to create the bandwith pools? 

always on the interface where the traffic LEAVES the ASG

How can I check that a traffic selector/pool is hit by the current traffic? 

not really at all, there is no tools or so, besides the bandwitdth monitor.

How can I configure QoS for VPNs? 

see kb article 293190

Can I maybe prioritize only outgoing traffic at all, no incoming traffic (the beginning of the QoS chapter in the manual sounds like that)??

Yes, you have read the documentation ;-) The QoS shaping works mainly for outgoing traffic - outgoing means "traffic that leaves the ASG on an interface"

And taking a look into the traffic with Ethereal shows that the packets are coming from :8080 to :.

How is the service specification of a traffic selector meant? The port of the selected service is considered to be the target port, no matter on which interface the selector is bound later on? In this case it would be clear that my selector can not work, because the traffic is *coming* from that port (8080), not *going* to that port.

ok, you are talking about the traffic which is created by clients which have the ASG http proxy  to surf the web. So it is on your internal (LAN) interface. The proxy downloads the web traffic on the EXTERNAL interface, so the QoS rule on the INTERNAL interface won´t help you anything there. YOu have to define guarantees for the non-httpttraffic (like VPN or VoIp) on the EXTERN IF then you will achive that the web proxy will try to limit it´s download speed. However, as the downloaded data is coming INTO the ASG, and the packet shaping is mainly for OUTGOING traffic, the efficiency of your efforts will be small.

[QUOTE=starfish4711;124722]Another question: I've created traffic selectors and bandwidth rules to guarantee bandwidth for one VPN tunnel. Hopefully it works, but so far I can not easily check this (one of my problems with Astaro's BW management). Would it make sense to use the TOS-Bits "minimize delay" in these traffic selectors?[QUOTE]

No, the TOS and DSCP Bits are only usefull if the traffic enters the ASG with these bits ALREADY set. The ASG doesn´t set these bits on traffic that didn´t have it set already.

Try using "iftop" on the command line to detect whether your QoS rules have en effect or not.

see kb article 293190

yes, that is basically what I have done.

ok, you are talking about the traffic which is created by clients which have the ASG http proxy  to surf the web. So it is on your internal (LAN) interface. The proxy downloads the web traffic on the EXTERNAL interface, so the QoS rule on the INTERNAL interface won´t help you anything there. YOu have to define guarantees for the non-httpttraffic (like VPN or VoIp) on the EXTERN IF then you will achive that the web proxy will try to limit it´s download speed. However, as the downloaded data is coming INTO the ASG, and the packet shaping is mainly for OUTGOING traffic, the efficiency of your efforts will be small.

Ok, but interesting point is, that a traffic selector for HTTP does work on the internal interface, as long as the http proxy is not involved. That means if I download a file directly through the firewall (by creating a temp. fw rule and disabling the proxy settings in my browser) the download speed is reduced by my bandwith pool at the internal interface (of course in this case the traffic selector is using protocol http and https instead of http proxy).

It's interesting because of the fact that in this case the traffic selector should not be able catch the traffic, giving the assumption that its protocol selection is looking at the *destination* port.

I've tested this with firmware 7.403, before I upgraded to 7.500 to follow BAlfson's suggestion (see my comment inside this thread). 

I admit that limiting the http traffic on the internal interface is not really what I wanted to do, but I guess that it would solve my problem: the traffic limit will delay the incoming download packets to the clients, causing the clients to demand the next download piece later as without the traffic limit.

No, the TOS and DSCP Bits are only usefull if the traffic enters the ASG with these bits ALREADY set. The ASG doesn´t set these bits on traffic that didn´t have it set already.

ok, besides the TOS/DSCP settings in a QoS rule, can I configure ASG to set this bits anywhere else (would it make sense to use these flags on the internet, I'm afraid  they are not used there anyway?)?

Try using "iftop" on the command line to detect whether your QoS rules have en effect or not.

nice tool, thanks! :-)

But how can I use it to check whether my QoS rules are working? Basically it shows the same info as the bandwidth monitor (just much faster, that's nice) and only because my "QoS enhanced" connection is listed here it does not prove that my rule is working. Or am I mistaken?

Ok, but interesting point is, that a traffic selector for HTTP does work on the internal interface, as long as the http proxy is not involved. That means if I download a file directly through the firewall (by creating a temp. fw rule and disabling the proxy settings in my browser) the download speed is reduced by my bandwith pool at the internal interface (of course in this case the traffic selector is using protocol http and https instead of http proxy).

Yes, it´s exactly like this. I think you even could make it WITH the proxy enabled, however the proxya will EXTERNALLY (on the WAN interface) always download with max speed.

 It's interesting because of the fact that in this case the traffic selector should not be able catch the traffic, giving the assumption that its protocol selection is looking at the *destination* port.

Hmm..think...think......it´s been a long time since I experimented with this so I am not 100% sure what trhe correct traffic selector would be. It can be that you have to define a "vice versa" selector (i.e. src-port 80, dest-poret 1:65535) so it matches. 

I admit that limiting the http traffic on the internal interface is not really what I wanted to do, but I guess that it would solve my problem: the traffic limit will delay the incoming download packets to the clients, causing the clients to demand the next download piece later as without the traffic limit.

Yes, it is not "elegant" (and may cause other problems on the WAN line because it can happen the client  will send out many retransmit packets) but in general, it works.

 ok, besides the TOS/DSCP settings in a QoS rule, can I configure ASG to set this bits anywhere else (would it make sense to use these flags on the internet, I'm afraid  they are not used there anyway?)?

No, you can´t (and - as you suspected on your own - it would help you much as no Internet provider really cares about those bits. It is normally used inside MPLS networks).

But how can I use it to check whether my QoS rules are working? Basically it shows the same info as the bandwidth monitor (just much faster, that's nice) and only because my "QoS enhanced" connection is listed here it does not prove that my rule is working. Or am I mistaken?

The only way I know to check whether a QoS rule matches is limiting the traffic in the rule so much, that you can "measure" it. I.E. if you wantr whether your http rule matches, simply define the rule, then confdigure it to use not more than 5 kBit/second. Then make a download. If it is slooooow, your rule matches, if not, it doesn´t :-)