how-to block ads
|
Airplane777
join:2004-06-20
4 edits | Monowall general Traffic Shaper queue approaches ?
Over the last week, I have been reading some of the past Monowall traffic shaper threads...and queues were mentioned. There seems to be several general approaches as to how people set up their Traffic Shaper up and down queue rules.
I was wondering if some people here could let us know how they have generally approached the setting up of their Monowall traffic shaper queues.
I'm wondering what the best queues to use are for a WISP operation.
Here are a few queue approaches that I have noticed:
1. Default Magic Shaper Wizard setup: There are a whole lot of default upload and download queues that the Magic Shaper puts into the Traffic Shaper: Rules section. Many are to put P2P in low priority. And others handle ACK, ESP, AH, ICMP, small packet download, small packet upload, etc. and these range from hated to high priority.
2. Upload queues only: mattwz was being helped by DaSneaky1D via a thread back in 2004. mattwz started out with the Magic Shaper rules and found out that he only needed 3 upload queues and no download queues.
mattwz wound up using DNS port 53 upload on high priority, ACK upload high priority, and All Other Upload onlow priority. Thats a big reduction in queues. And no download queues.
DaSneaky1D said that the download is considered a "low cost" connection...which means that over utilization of it is less likely compared to the upload, so there is no gain or loss to doing shaping for download. (I don't know if I understand that or not). I'm a little worried that I still might need download queues. Maybe I just don't understand why I might not need any download queues at all.
3. A few high priority queues...rest on low priority: I have seen someone else said to just put the most important protocols that you will be using on medium to high priority, and the rest put at low priority. The low priority will take care of all the P2P programs.
4. Queues to shapre P2P only: I noticed in a thread that cmaenginsb only shapes P2P and lets the rest go.
With all the choices, I'm a little confused as to the best queue approach for a WISP operation. I don't think I will be using the Magic Shaper rules, since I believe I remember DaSneaky1D advising against it...that they all weren't necessary.
It would be great to hear how you all generally approach the setting up of your queues, and if they are upload only, or upload and download.
With respect to the above general queue approaches, I wonder what the best queue approach to take would be for a WISP operation using Monowall? It seems there are several ways to possibly go? But maybe there is one best way for a WISP?
Thanks in advance. | |
cmaenginsb
Premium,MVM
join:2001-03-19
Palmdale, CA
| Since we rate limit our customers, I will restate the only thing we queue is PTP. My opinion is that once the traffic has left your network it will not be prioritized anyway and it's cheap to have a high capacity network (with the exception of the upstream).
If you are using an asymetric line like DSL then upload would be a higher cost connection. In general though I'm not sure you'll see an advantage prioritizing DNS traffic when it consists primarily of small packets.
At the end of the day, just like radio choice your choice in traffic shaping is going to reflect your business ideas.
--
CCNA, Comtrain Certified Tower Climber | |
Airplane777
join:2004-06-20
4 edits | Hi cmaenginsb:
Thanks for your post.
I know that you, DaSneaky, Lutful, SuperDog, and others here are on really on top of this stuff, so I thought I'd put this thread forward to see if it will help me see the best way to do my queues.
You may have hit the nail on the head for me when you said, "At the end of the day, just like radio choice your choice in traffic shaping is going to reflect your business ideas." Maybe my question should have been:
Queueing choices vs business ideas ?
I too plan to rate limit my customers. I will be using an ADSL line.
You said, "...it's cheap to have a high capacity network (with the exception of the upstream)". By "cheap" do you mean something similiar to what DaSneaky1D said?
DaSneaky1D said, "...download is considered a "low cost" connection...which means that over utilization of it is less likely compared to the upload, so there is no gain or loss to doing shaping for download."
Do both of you mean that since there is so much download BW, that all that download BW probably won't hinder the incoming data, and thus there is no need to even try to have a queue for incoming data packets. That is queueing won't help incoming data at all (as long as the incoming data isn't congested).
Are both of you saying (in slightly different words) that since download is so much higher BW then the upload BW, that the high download BW doesn't need priortization of data? Or IOW, if a WISP is offering high enough BW on the download side, that incoming data won't be hindered as the incoming data is going on to our WISP customers? And since the incoming data won't be hindered (no matter in which order it is coming in at), that this incoming data will travel to a WISP customer unhindered and unblocked. Did I say that right?
But since the upload BW is so much lower in an ADSL circuit, I should do queues for the uploaded data because if uploaded data isn't handeled efficiently (since the upload BW is so low), improperly handeled upload data could affect proper downloading of data?
Upload que of ACK: ACK data should be queued to be sent out with high priority, so that the server that is downloading data to us, will know very quickly that we have received that servers data. Do I have that right?
Upload queue of DNS: And DNS upload should have high priority, in order for people who are browsing to have quick downloads when they browse using their browser.
Upload queue of VoIP and IP video: And maybe VoIP and IP video on the upload side should be queued for high priority, since it is so time sensitive and we are able to control that. VoIP is two way, but I imagine IP video is mainly just one way.
All other upload: I assume I would make everything else low priority, which would include all P2P. Am I correct in thinking that I don't have to worry too much about P2P download?
With all that said, I'm still wondering if we should consider queueing for incoming data due to the oversubscription we do. We have to do oversubscription to make a profit so we do oversubscription and the incoming data probably could get congested at times. That makes me think that maybe we WISPs should be doing queueing on incoming data, just because we do oversubscription, which will congest incoming data.
It would be great to hear how other WISPs approach their queueing. | |
cmaenginsb
Premium,MVM
join:2001-03-19
Palmdale, CA
| reply to Airplane777
No, I mean it's cheap to build your internal network with high speeds. Unless you are using an asymetric line (like ADSL or cable) your upload speeds are the same as your download speeds.
There really isn't "so much download bw" when you think about it, almost 80% of the total traffic will be download traffic.
Think about what it takes to load a simple web page. On the upload side you have the original request and the acks all of which are really tiny packets. On the download side you have the page itself and the graphic files which can be quite large depending on the webpage.
The one thing that breaks this is peer to peer since the software uses your computer to share files with others, so you are getting a lot of upload traffic because of it. You are incorrect as p2p traffic is the most important thing to reduce on your network.
ACKs and DNS traffic are so small I wouldn't even bother doing anything special with them.
As to VOIP, that's something I might queue seperately but I would apply a queue in both directions for it if I did.
IP video? Are you planning on having having customers host their own movies or security video servers? IP video is UDP meaning that if a customer is downloading video from somewhere there will be no upstream traffic. As to hosting security servers we've installed these on DSL lines so I have some direct experience. A low quality 8 camera server will max out the 512k upload found on some DSL circuits. A higher quality server will require 1 M or more upload for someone to view it remotely.
As I said before, do you feel it's important to prioritize VOIP? We don't so we don't do it.
There is no good technical reason to prioritize DNS or upstream ACKs although the impact of doing so won't be much. If you're so concerned about DNS then use the monowall box as a caching DNS server and have your customers point to it.
P2P is the worst thing to happen to ISPs in general in the last few years, it has made it so that anyone with any technical ability can trade files, therefore increasing that traffic.
--
CCNA, Comtrain Certified Tower Climber | |
John Galt
Forward, March
Premium
join:2004-09-30
Happy Camp
 ·CenturyLink
| said by cmaenginsb  :As to hosting security servers we've installed these on DSL lines so I have some direct experience. A low quality 8 camera server will max out the 512k upload found on some DSL circuits. A higher quality server will require 1 M or more upload for someone to view it remotely. What was the pic size and frame rate?
--
A is A | |
Airplane777
join:2004-06-20
4 edits | reply to cmaenginsb
said by cmaenginsb :The one thing that breaks this is peer to peer since the software uses your computer to share files with others, so you are getting a lot of upload traffic because of it. You are incorrect as p2p traffic is the most important thing to reduce on your network. Thanks cmaenginsb for your reply.
Last night I set up my AP with DHCP again to make it available again to my neighbors. You might remember that I had one or two neighbors that were constantly sending and receiving data, as noted by the LED on my WISP interface. I checked the Traffic Graph last night and sure enough they were sending out way more data then they were receiving. Looks like they were doing P2P. I wonder if it was a virus on their machine, cause it was non-stop. Or maybe it could be a DOS attack. I don't know that Monowall can defend against DOS attacks?
I'm going to have to find a way to make that P2P stuff at the bottom of the low priority list.
Gee...that video really takes up a lot of BW. I may have to wait til I get a larger pipe.
Since WISPs routinely oversubscribe (as all ISPs usually do), I figure there will be congestion of the downloaded data at times. Maybe there isn't anything much Monowall can do about that with queues? Probably just try to get a larger pipe to the ISP?
If I didn't use hardly any queues at all, as you suggest, and only used up and down rate limits for WISP customers, then does it matter if I rate limit WISP customers by static pipes or virtual pipes? Or are virtual pipes still the best way to rate limit? | |
cmaenginsb
Premium,MVM
join:2001-03-19
Palmdale, CA
| reply to Airplane777
Virtual pipes are best because it reduces the number of rules needed which brings down processing requirements and management headaches.
My best answer and the one we followed since this operation had just a single T-1 is to watch your traffic using MRTG or other traffic grapher and when you start to see spikes maxing you out add another line.
DOS attacks are tricky as it's very easy to flood a DSL or T-1 and effectively shut it down. The only way this can be fixed is port filtering at the upstream side so if you get attacked from the outside world you need your providers help. Usually that type of help is only available to T-1 customers giving them a bit of an edge.
As to video it was 15 FPS at CIF size. | |
|
