QoS Philosophy

[pbix]

Hi Eric,
I have been working with DD-WRT for a couple of years now and recently came upon your work with Gargoyle. I am intrigued by your stated philosophy to keep your interface clean and simple in order to make the experience for new users straight forward. Other features are available to power users via the command prompt.

I have successfully flashed a new WRT54G-TM with your software. (A procedure I could share if you like) and started to play with your interface.

I have a particular interest in QoS since this is something that is pretty broken over in the DD-WRT world. Looking at how you arranged your qdisc, classes and filters it seems OK but I am curious how you came up with this. There seems to be countless ways to implement QoS and so maybe you could tell us what goals you had in mind. One thing I notice is that you have different upload vs. download filtering. This seems counter to your keep it simple philosophy. Also you chose to put your qdiscs on the LAN side rather than the WAN side so what is the idea there?

I'll look forward to your response.

[Eric]

First, QoS is inherently complicated. While I dowant to try to keep things simple, I suspect that only somewhat more advanced users will know what QoS is and be able to use this feature. I've tried to make it as straightforward as possible... but I'm reluctant to start cutting too many features (like different upload/download configuration) just so more people will be able to use it. There's an Einstein quote that sums up the situation well: "Make everything as simple as possible, but no simpler." (Actually, that would be a pretty good motto for Gargoyle as a whole.)

I set up QoS the way I did mostly because it seemed a reasonable solution to me. As you say, there are a huge number of ways to set things up, and this seemed a good, straightforward solution.

One very good reason to split upload/download traffic is that if you match the source ip/port in upload traffic, matching the source in the same way for download traffic is not the same! You'll match the remote host instead of the local one unless you match the destination, not the source. One good way around this is to specify local vs remote in the user configuration and have the script automatically take care of handling this, but I haven't gotten around to implementing this yet. Still.. there's a lot of differences between upload and download usage (for one you usually have a lot more download bandwidth to play with), and I therefore think it's a good idea to keep upload/download seperate

Another goal I had was to make use of the burst parameters in HSFC -- this can (theoretically) allow a VOIP connection (or other connection where delay needs to be minimized) to better share bandwidth with connections where all that matters is the overall speed of the transfer.

Finally, I wanted to priorities SYN/ACK packets, so connections get established quickly but not force the user to worry about this step, so there's a hidden class that automatically prioritizes this traffic.

Regarding the qdiscs you are mistaken... they are on the WAN side, not the LAN side. If they are showing up on the LAN side, that's a bug, but I just checked on my local router with the latest build (though I haven't modified QoS in a while) and "tc qdisc show" clearly indicates that they are associated with the WAN interface.

Naturally, I'm not perfect, and there may be a much clearer way to do this (though nothing springs readily to mind). I'd love to hear your input/suggestions on how this configuration could be improved.

[pbix]

Hmm.

Might be a long discussion.

Let start with the devices your using for you qdiscs. I must admit that at the moment I have this router set in wireless bridge mode. So then I suppose that lan-br could be interpreted as the WAN interface device in that case.

Tomorrow I will try the actually using the WAN ethernet port. Then maybe I will find you are correct about the qdisc being on the WAN port.

Working with folks over at the DD-WRT forum you see a lot of different goals for QoS especially with more advanced users. But for the basic user you have three types of traffic.

First there is the VoIP/Online Game traffic which is actually quite low bandwidth by needs low delay,

Second you have your "normal traffic" which is what most people need and basically has no delay requirement other than "go as fast as possible"

Finally you have your low priority traffic like bittorrents that people just do not want to interfere with their other two types of traffic.

I have to tell you that based on my experience with your typical user there is little chance that your current QoS screens will let them be successful solving the above basic problem. No offense to you or Einstein.

I like the fact that you apply hfsc because it does seem to be the most advanced QoS thing going in Linux. I've spent quite a bit of time studying it in the last 6 months. Not very well documented which leads to lots of not so well designed implementations.

Anyway I was thinking to get involved more in Gargoyle if I thought your were serious about making a user interface for the common man.

[DoesItMatter]

I think one of the BIGGEST problems with QoS is the general thinking that it will solve bandwidth issues.

From all the posts I've seen here and on the DD-WRT forums, MUCH of it is centered around people doing torrents and having bandwidth issues.

Torrents can be controlled via Bittorrent, or any other torrent program, by manually allocating a certain # of connections and bandwidth to each download.

Myself, I think people doing any torrents are individuals just waiting to get caught, because there is NO such thing as anonymous torrents. People who belive any torrent is truly anonymous probably still believes in Santa Claus and the Easter Bunny.

I've done Linux distro torrents, 100% legal, for testing purposes myself.

I grabbed 6 torrents, DVD images (about 4GB in size) and then had them all running at once.

One of my home connections (I have 2 independent cable ISP's inbound to my house, different companies, so different bandwidth) is a connection of 10mbps down, 768kbps up.

I set each of these 6 dvd images to be a max of 64kbps upload, which would be maximum 384kbps upload bandwidth used at the max.

This testing was done on a Fonera 2201+, overclocked to 200MHZ

At the maximum, I had about 200 incoming connections, and 384kbps upload speed used up.

I still had all that download bandwidth available PLUS 384kbps upload bandwidth.

My internet had slowed to a CRAWL, any internet browsing, no matter what site, took anywhere from 30 seconds to 1 minute to load. I had the bandwidth, but what was happening is the router itself could not keep up with all those connections.

QoS in itself could be great, but it really needs much more hardware than a simple home based router and, from what I've seen and tested, is really useless with torrent junkies.

[pbix]

Well I agree that there are lots of illegal things going on with bittorrents and I do not want to be part of that.

But in contrast to your story I recently helped a guy who has a torrent client that actually ran on the router itself (under Linux) and used the USB connection of the router to write to a hard drive. I thought this was a pretty cool application of router functions available. Anyway he wanted to let the torrent consume all available bandwidth unless he started using something else like his VoIP phone or watching youtube. We got it working just like he wanted. In his case his line was 760k down and 90kup. At the point that the link was maxed out the router was at 25% load. So I will tell you that such things can be done and they can be done on a 200Mhz router.

What firmware did you use that caused you to get CPU bound at only 384k?

This is another thing I see about Gargoyle's implementation. That is while it is technically correct it may not be as CPU efficient as it could be.

[DoesItMatter]

Firmware being used was one of the 1.0.x of Gargoyle.

I've used DD-WRT for a while as well, and been a forum member
there for a while. Lot of posts there also about torrents
and how it clogs up the router and makes it very sluggish
even though there's lots of RAM available.

I'll try flashing the Fon with a current beta SP2 of DD-WRT
and try more torrents.

If you're a member of the DD-WRT forums, you'll probably be
aware of Sash, one of the moderators. Some of his posts have
suggested for torrents with DD-WRT you need a router with
8MB/32MB config and over 300mhz because DD-WRT takes
up cpu utilization as well and too many torrent connections,
even with LOTS of bandwidth available, will drag down the
router and make any other internet sluggish.

[pbix]

Sounds like a plan. Look for the thread
"Problem with QOS, rtorrent, youtube" over at DD-WRT. Its quite long but read it all and follow my instructions there. I will check for a post from you on that thread and respond if you have issues.

Anyway in this thread I want to talk about Gargoyle so back to that discussion.

Another goal I had was to make use of the burst parameters in HSFC -- this can (theoretically) allow a VOIP connection (or other

I like this goal but I do not see any rules to support this goal. How did you plan for this to work?

[Eric]

You're right that, by far, the biggest flaw with my implementation is that it tends to chew up the CPU. I'd love to figure out a good way to minimize CPU usage, and if you have any suggestions, I'm very open to them. Also, I seem to recall Does_It_Matter is using a Fonera device, which has a particularly small CPU.

Regarding the burst parameters in HFSC (sorry, HSFC was a typo), the minimize_delay parameter introduces an initial burst for all traffic classes that have it, while everything else has this initial burst rate set to zero. While overall the traffic bandwidth will be the limit set, the burst helps to minimize delay.

You're right that the QoS will apply to the LAN if you're in bridge mode (since there are no other interfaces available). When the WAN is up, it will apply to that.

I am "serious about making an interface for the common man", as you say, but so far I'm the only one working on it. That means there are a LOT of areas that need work (QoS being one of them), and I have only so much time to address all of them. If you're serious about wanting to help, that would be GREAT! I am by no means wedded to my current design of the QoS section, and if you have a better strategy you would like to propose (and even better, help implement!) I'm all ears...

[pbix]

In a few days I will have a Linux development platform up so I can extract your sources and make some designs and suggestions. The idea will be as I said to make an implementation that solves the basic issues I outlined out of the box so your novice user can just turn it on and get some value.

It will also have a straight forward way for a power user to change/extend the design so complaints from power users will not be too deafening.

BTW, I added a section on installing on the WRT54G-TM to the Wiki.

[Eric]

Thanks for updating the wiki! It's always great to have more documentation.

I look forward to hearing what you have in mind for improving QoS. Let me know when you're new linux box is set up, and you have some proposed improvements to the code.