Qos and ACK packages

[hotzenpl0tz]

Excuse my ignorance on the topic but I wanted to know if there is a way to priorize ACK packages in the qos upload section (or is that already done ?). The reason is, that atm I have a webserver behind the router that has qos upload rules set to fastest for port 80. What now happens is that if somebody downloads from the webserver (and I do want him to be able to download with good speeds, hence the fastest rule) then webradio streams start to buffer quite alot und don't run without interrupts. Now I figured I could add another class, one above fastest (or one in between and put the webserver there) and use the fastest class either for the ports the webradio uses, or even better: use it for ACK packages since in theory shouldn't that solve the buffering problems because the webradio packets are sent out quick enough ?
If my thinking is completely wrong, somebody here with a bit of experience that knows what would be a good setup for my requirements ? Thanks guys !

[Eric]

Actually, there's already a hidden class that prioritizes SYN/ACK packets so TCP connections can be established quickly even if bandwidth is maxed out.

I'm guessing (though I can't be sure unless you're more specific) the web radio uses a UDP connection which doesn't use SYN/ACK anyway. Try classifying web radio packets to a service class with relatively high priority, and with "minimize delay" checked. That should help somewhat, but depending on how much bandwidth each type of connection requires, and how much you have, it still may be tricky to get both types of connections to work smoothly.

[hotzenpl0tz]

The webradio that is used alot in my network ist lastfm.com - and they stream over a normal http port80 connection. What I now tried was the following:

Source: 192.168.x.10, Source Port: 80 Fast
Destination Port: 80 Fastest

I am hoping that now uploads that come from my webserver are put into the fast class and regular port 80 uploads (hoping that that is how the ack packages for the lastfm stream can be qos classified - I might have to wireshark this and see if there is anything else going on) are put into the fastest class. No idea if it will work though, I think this will take some tweaking

[hotzenpl0tz]

I have another question on how the qos implementation works. At the moment somebody is downloading off of my webserver. If I check the current connections in the webinterface I see for example:

Pr Src Dest Upload DL
tcp 217.228.22.xx:3807 92.230.xx.182:8080 0.373 MBytes 11.572 MBytes

Now this is for one thing very strange: the second shown ip is my own external ip. Port 8080 on my external ip is a port-forward to my webserver (being 192.168.x.x in my LAN). Since I know that atm somebody is downloading off of the server and this is the only connection with bandwidth big enough that is showing up in the current connections I know this has to represent the download. The strange thing now is: the Upload/Download statistic seems to be switched around. The 11.572 MB has to be what I uploaded. Same thing for the IPs - shouldn't that be the other way around ? Since I am uploading, the connection on port should be 92.230.xx.182:8080 or am I thinking wrong here ?

This is confusing me even more, since I was actually looking for my internal IP being the src on port 80 - so I was expecting something like:

tcp 192.168.x.x:80 217.228.22.xx:3807 11 MBytes 2MBytes

which I could then classify in Qos with:
source ip: 192.168.x.x
source port: 80
service class: fast

I am sorry if my questions stem from the fact that my network knowledge is a bit limited - but since this maybe could also be a problem with how the data is represented I though I would ask.


-----------
This is how this is setup:


| WebSrv |:80 <> | Router |:8080 <> | Guy |

192.168.x.x | intIP / extIP/dyndns | someip

There is some more trickery going on on the webserver where port 80 goes to a transparent reverse proxy that then forwards connections to several different webservers on the server, but that shouldn't matter I would believe, since I want to put all webserver uploads into one service class.

[Eric]

I think the issue here is the connections section. Source and destination are relative. Right now (I think) I'm making sure that if one end point of the connection is in the LAN, the end in the LAN is listed as the source, but here since neither end is in the lan (there's a connection via port forward, which isn't getting detected in conntrack), this isn't checked. So, it looks backwards.

Also, source/destination is relative in the QoS sections. In the QoS upload section, the source is the local ip (it's being applied to outbound packets, so the source is the local network). In the QoS download section the source is the remote ip (here QoS is being applied to inbound packets, so the source is remote and the destination is local).

My plan is to revise the QoS sections at some point to be more like the access restrictions section, which has a more flexible classification system, and also labels "local ip" and "remote ip" vs source/destination. This may clarify the issue.