Slashdot Mirror
Traffic Shaping on DSL?
jackla asks: "I'm now looking for software to do traffic-control on my Windows XP box. I am connected with DSL and my upstream is capped at 96kbit/s (down is 1.5Mbit/s) - this means that high(>70kbit/s) upstream utilisation KILLS my downstream: it just drops down to about 400kbit/s and stays there unless there's more upstream space. That said, I read alot about the Linux shaping solution (wondershaper or something) which sounds exactly right, except I need something that works for Windows. What I want to do is prioritize upstream ACKs (for example) so that my downstream isn't affected by upstream use.
If anyone heard of a peace of software that can do this, I would love to hear about it." It would be nice if something like this existed cheaply for Windows. I am unaware of such, but maybe a few of you have ideas. Could such a traffic shaper be built using low powered computers? If so, how would you build and configure it so it would maintain compatibility for the single Windows machine, behind it? (Think: homebuilt traffic-shapping appliance)
I have DSL through Telus in Canada with the same upstream cap, and high upstream utilization means a very, very minimal hit to my downstream speed. Perhaps it is more of a hardware issue than anything else? Or rather, something that you should be asking your DSL provider about instead of the general Slashdot community? *shrug*
> 400 kbit down stream is not bad at all.
Unless you're paying for 1.5Mbit (which it sounds like he is), in which case it sucks. 400k isn't bad, but it's only about a quarter of 1.5M. That's a BIG difference if you're transferring a large file (e.g. a movie), and is even more apparent if you're trying to (e.g.) stream video.
Not everything that can be measured matters; Not everything that matters can be measured.
Couldn't he reduce the number of ACK's by increasing his window size?
I'm not a TCP guru, but I think this would potentially cause just as much of a problem. If, for example, he has a larger window, then when he has packet loss there will be a tremendous penalty. Instead of perhaps a number of small lost packets, he loses a number of _large_ packets. I could be wrong.. but I think this is one of those tradeoff situations.. catch-22 and all that.
You're correct, there IS a fine line between support and discussion. With support, the same issues appear again and again. With discussion, an issue is talked about once, and never appears again unless there's new information.
Personally, I think that Traffic Shaping is a fine topic for discussion. If it also answers someones technical question, then all the better! But if this topic appears again in the next few months, though, then that has stepped over the line.
There has been an extremely large number of trolls lately, and, as these answers suggest, very little useful information. This may in fact be a hard question, but must we compensate ignorance with stupidity?
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
This really isn't true. This can be fixed locally.
/.)
Consider: his problem is that his upstream provider is deciding what packets to throw away, and is making bad decisions.
If he installs a local rate limiter, such that the upstream bandwidth is never oversaturated, the provider will no longer be making decisions about packet drops... he will be making them locally, and can prioritize them however he likes. Since he decides what gets dropped, he can pass the ACK packets first.
That said... doing this with Windows isn't easy. I'm not that familiar with it, but Routing and Remote Access Services *might* have something along this line. I'd suggest perusing the Microsoft web site to see if there's anything like that. (or someone else may post this info here on
At work, we're doing bandwidth management on a 40 megabit connection, using software from www.etinc.com. It runs on Linux or FreeBSD. I'm mentioning it here not so much for this question, but as a general-purpose recommendation for people trying to do bandwidth management on large connections. This software costs about $700 and is closed-source, but it works really well. The earlier version we have totally choked and died, but the 3.21 version does exactly what it says it will.
I'm still not sure, offhand, how you'd use that software to solve this specific problem. You can prioritize and limit based on ports and source/destination, but I'm not sure offhand that you could use bwmgr to optimize based on packet payloads.
Basically, what it REALLY sounds like is that the connection is TOO asymmetric and that he might consider an alternate provider, if available.
The asymmetry of ADSL is a business not a technical "feature" - and it's based not on some wild conspiracy to stamp out freedom and file sharing (as in the response far above this one) but on the sound knowledge that most traffic just is asymmetric - typically you have 1500 bytes of webpage arriving downstream for every 40 byte acknowledgement you send upstream, at least in the use-model that ADSL was constructed on. So it would just be a plain old waste of money to provision for symmetric network use.
Where I am, we have a network of about 80 users sharing a 2M down, 256k up, ADSL connection. This worked fine until some of our users discovered gnutella.
Gnutella is a very bandwidth-hungry protocol, and tends to saturate the upstream bandwidth on ADSL. This resulted in dramatic loss of performance for our web users, for reasons explained above (namely that since acks get delayed, the nagel algorithm on the other end kicks in, reading this as general congestion, and slows the sending rate down dramatically.
I fixed this by installing iptables and the tc ("traffic control") application on the linux box we use for a router. This works using "class based queueing" - you divide up your traffic into several classes, depending what their source and destination IP and ports are (or if they're related to other traffic, with particular ports and IPs). And then you give each class a bandwidth limit (hard or soft).
The way we do this is to use the iptables (successor of ipchains) functionality to insert a "marker" into each relevant packet, and then have tc put them into the appropriate class based on that mark - this gives you all the selectivity (and clarity!) of picking packets that iptables offers.
In our simple setup, reserving 64k or so of bandwidth purely for acks going back to web servers (ie going to port 80) and a few other types of traffic, and a bit of fine tuning, is enough to keep the connection very usable, and let people use gnutella on it as well (at a rate that's reduced a little.)
In the face of constant gnutella traffic, this improved our web connectivity by about 900% rather than 10%. Since you only send a 40 byte ack for each 1500 bytes you receive, a ratio of about 37:1, reserving 64k for acks is enough to cover for 37*64 = (over 2M) downstream traffic.
If you run, say, a local ftp server, you could isolate the traffic from that very easily by marking packets which originate from port 20 and 21 on its IP address (assuming the ftp server is well-behaved and sends its data-connection packets from port 20) and limiting them so that you save 30k or whatever upstream for your other traffic.
None of this needs to be done at or beyond the provider's equipment. Because we limit the rate at which we send traffic to the provider, their equipment doesn't get its queue filled, ever! (unless they're not fulfilling their committed data rate, which we can't really control).
So a local solution may be entirely possible - this will depend on just what traffic is clogging up the upstream.
As for specific software recommendations, I don't know of anything that does this on windows, personally. I suspect it's likely to be payware, and will cost more than an old PC that you can run linux on. We're using a P133 with 32M and I have a feeling that it's slightly overspecified (at least on RAM - I think 16 or likely 8 M would do fine).
.sigs: Just Say No!
His upstream is 96Kbit, and his downstream is 1.5Mbit.
In round numbers, this means his upstream is slightly less than 1/16th his downstream.
Say his MTU is 1500 bytes. Let's say his ACK packets are 64 bytes (we were generous on the 1/16th, so 64 instead of 60 is not that far off).
That basically means that, assuming no packets are lost, and that all ACK packets are precisely equally spaced, then 2/3rds of his upstream bandwidth needs to be dedicated to ACK traffic for the downstream bandwidth.
Why do we have to assume equal spacing? Because he can't control anything other than his send order, because he can't control the rate limiting machine's discard.
Is it possible to do this with a traffic shaper on the client machine? Yes, with a very sophisticated traffic shaper, which maintains stateful information (e.g. like a PIX firewall maintains per connection state information). It's possible because now we know the numbers for his connection -- we don't know the general numbers, though, for *any* assymetric link, so this isn't something you could make into an installable package, without the user having to resort to math/tuning tools.
Even so... this only works if the traffic is connection oriented. So far, people have asked -- and he hasn't responded -- about the kind of traffic he's running.
If the download traffic is RTSP or UDP or any protocol based on packets other than TCP packets, then there's no way to make preference choices on packets sent out. And then he's back in exactly the same boat he was in before.
So it's not possible to say "install this", and it's not possible to say "install this, and set these tuning values based on your relative upstream and downstream speeds", unless you really limit the problem you are trying to solve.
Doing that will probably not be satisfying, since the primary reason for a (mostly) unidirectional pipe is to push content to users, and most content streaming protocols are not based on TCP or other things which can be stateful.
-- Terry
"By increasing the recieve window you are essentially reducing the amount of ACK's that must be sent per data recieved."
The problem with this theory is that you need to keep sending ACKs all the time to keep the window sliding. Yes, if you were to only send ACKs starting at 50% of the window size received, and you had a large enough receive window that the propagation delay for an ACK through a totally saturated link was less than 50% of the time necessary to receive the data being ACK'ed, and the rate limiter queued all packets, instead of just droping them, then you'd be right.
But that's not what you do.
The point of a windowed protocol is that you eat a single round trip latency over a very large data stream consisting of a large number of packets, and what you are saying is that it will act as if TCP/IP is a lock-step fixed window protocol. This just isn't true.
So you compete for transmit space with the same number of ACK packets.
The problem is still that you need 2/3 of the send bandwith just for ACKs on a saturated receive bandwidth.
I would be really surprised if the send bandwidth limit wasn't set with *exactly this* in mind: large enough to handle full speed receives with an MTU of 1500 and an ACK packet size of 60 bytes, plus 50% (1.5Mb/96Kbit = 16, 1500/60 = 25, 25/16 = 150%).
-- Terry