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)
LRP's project might be of some use. Yes, it means getting a cheap box to run Linux, but then you can use all of that real neat networking software that's available for Linux boxes but isn't available for Windoze boxes.
Not everything that can be measured matters; Not everything that matters can be measured.
If you're using Linux on the firewall machine, make sure you enable QoS and ALL the modules in it. Then grab cbq.init and set up the traffic shaping rules. The script file is well documented.
-F-
Instead of sarcastic comments about "run linux" "format c:" blah blah, check out this kbase entry from MS regarding the packet scheduler. It might be useful to you.
If you know the Linux program, why don't you just use Linux for the network controller? Have the Linux box be used as a gateway, running ipchains and the wondershaper. Linux is not that hard. Linux can also be run on an early machine. I am running Red Hat 7.2 on an AMD 133 with 48 mb of ram. I am running in command line, which is hard for a beginner to learn, but it is running dhcpd and Samba nicely. I would recommend Linux because security is easier to setup and maintain than Windows. Windows you will never know what ports are open or who is watching. Linux you can close ports alittle easier, much better for server (or routers/gateways). Why Live on Windows? Most of the programs you need for network admin are free.
Linux, because Windows XP is eXPerimental!
TCP has to send back replies ("ACK"s, or acknowledgements) for each of the packets it receives, so that the sender knows if it needs to retransmit a packet. This is part of how transfer control is achieved by the protocol. So, if there's less space for ACKs going upstream, then the tcp traffic in the other direction can get slowed down.
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
All DSL modems have a queue for outgoing packets. The queue will be a fifo queue, so once packets enter the queue there is no way to remove them.
If you are uploading, then the queue on the router will be full of packets...
If you are also downloading, then the ACK packets acknowledging the downloaded bytes will have to wait on the queue on the DSL router.
The fact that these ACK packets are getting delayed will slow down subsequent data packets being sent, and the downstream transfer rate will drop as a result.
By limiting the rate at which packets are sent to the DSL router, we can remove the queue from the router, and move it back onto a linux machine, where we can then prioritise the traffic as we see fit. ACK packets are allowed to skip to the head of the queue, so download speed can be maintained.
Hope that explains things
what is going upstream from your pc. You can download an eval. version of Iris ( a sniffer ) and see the traffic originating from your pc destined to outside your network.
You might find something crazy going on because a non-serving pc should be pretty quite. You will see broadcasts and ACK's but thats normal. If your computer is spewing traffic and you can't find the source your NIC could be off in the weeds or you may have been hacked (not uncommon with windows and DSL/Cable). I have 38 IP's in hosts.deny because of detected port scanning on my DSL.
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
I believe XP comes with the "QoS Packet Scheduler" and has it installed by default. I believe it can do what you ask.
Could such a traffic shaper be built using low powered computers?
Fire up that 90MHz Pentium, install FreeBSD, and build a kernel with bridging and dummynet enabled. Dummynet is an awesome network simulator. Just set up a couple of ipfw rules for the types of traffic you want to limit, and then set the bandwidth parameters in dummynet. It's very easy to do basic stuff like you're describing, but you can do all kinds of other things with dummynet... latecy, loss, queue limits, simulating multiple hops and multipath links with different latencies. There are no tools of this caliber (let alone free!) for Windows.
Next question?
Try this.
20% of TCP trafic is the "reply" stream.
so if you cut 20% of the reply you slow the downstream..
Make any more sense?
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
Linux has rather impressive QoS facilities (so many options that it has an entire submenu in menuconfig). What you'll want is some floppy router distribution (mine's not quite ready yet, but I hear LRP has most of these options) and a decently powerful machine (100-200MHz pentium with 32-64MB should PLENTY for a DSL, but remember, you're not just routing/NATting).
There are tons of preconfigured things out there, but you might want to read up on tc (the traffic control manipulator, part of the iproute2 distribution), ip (from iproute2) and iptables (to help classify packets) before you dive in. The kernel ships with most of what you'll need (including the common CBQ scheduler), but there is a really cool scheduler known as HTB that is more accurate because it's resolution is traffic based, not time based. If you want to shape inbound traffic destined to teh router itself, you'll also need the IMQ patch.
Hope this helps. If you want more info, EFNet #iptables, look for KurD, the human router. He plays with this stuff all day at his job.
--MonMotha
You are correct. The problem that needs to be solved is how to insure his ack messages make it out, proioritized above any other traffic being sent. As for the example of streaming video though, that is not the case as video runs on udp, which has no ack, so this only becomes an issue with large file downloads...
Unless I'm mistaken, that won't hlep.
What the QoS scheduler does in windows is permit applications who specifically request a certain qos to keep it. Í don't think it's a robus, configurable queuing system.
Bandwidth Limiting HOWTO might be of some assitance? Or not... either way. It just caught my eye on linuxdoc.
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
So yes, traffic shaping can be your friend. Unfortunately, it may be hard to know what to tune it too, depending on where the bottleneck is.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I've been running BBIagent
http://www.bbiagent.net
for about the last year or so. I share my DSL with a few neighbors via some cat5 we strung up over the last year, and my counterstrikin was startin to hurt real bad whenever one of the teenager kids was downloading from kazza
Before I was using a linksys router. My current BBIagent setup is a packard bell p60 with 32 megs of ram, and 2 old 16 bit isa 3com nics. The performance increase is stunning.
You can specify what kind of traffic to create priority for, forward, block ports. There are a few options for hack detection blocking. The nicest features of bbiagent is.
1. Single floppy distro which is configured on the fly via the bbiagent website
2. Java app for admining the sucker, very well laid out.
3. Realtime control over your network connection without losing it. On my linkstink whenever I would change a rule or a forward the whole thing would reboot itself, bbiagent doesnt do that.
4. Open source!
5. Linux Based!
I can go on and on about it, but if you're really looking to control what and how packets are handled, I would really recomend giving bbiagent a try.
--toq
The reason your downstream rate gets limited by your upstream rate limit is because of your inability to send acknowledgements upstream for the downstream packets you are receiving because of the congestion on the upstream link.
Once the advertised receive window is filled with packets, the remote side is not going to send any more data until it gets an ack from your computer.
At the point that the rate is being limited, the way to fix this is to give preference to ACK packets -- i.e. packets without payload.
The problem is that this has to be done at the point the rate is being limited, which is at your providers router, not at your router, and not at your Windows machine.
Installing the Microsoft packet scheduler, or some UNIX box with a real netowrking stack that you can exercise fine control over packet priority, as some people have suggested, isn't really going to fix your problem, except by maybe 10% (the exact amount depends on your average outbound payload size relative to an "empty" ACK-only packet).
This is because the problem is the queued data in the transmit buffer in the rate limiting device not containing your ACK's for inbound data.
Really, the TCP/IP protocol wasn't built for asymmetric reates, without equally asymmetric data transfers.
Effectively, you need to be able to control the transmission of data packets from your end based on knowledge of how full the input buffor on the outbound leg for the rate limiting device gets, so that you can throttle your data payload packets accordingly, to keep that buffer as empty as possible.
The only way you can really do this is to put code in your stack to monitor the advertised window from the other side, and the locally classify outbound packets as to whether or not they contain data payload, or are merely acks. You basically have to avoid filling the outbound queue on the rate limiter above 50%.
In an ideal world, the machine doing the rate limiting would do this for you. Some rate limiting machines for asynchronous connection do this, and it's not a problem (you can see the posts from the people who are rate limited, and don't understand your problem). But those machines are more expensive, and it's just as well for the provider if you feel pain as feedback for uploading, since it serves their purpose in providing you asymmetric service in the first place.
The problem's a lot easier when you are trying to avoid filling the inbound receive buffer for a router with a speed differential on one side (e.g. the inbound receive buffer on a router connected to a dialup modem bank, with a customer on a modem wanting to do QoS based on protocol type, so their SSH didn't lock up when an FTP or large HTTP transfer started up). *That's* where things like "AltQ" and the Microsoft packet scheduling engine become useful... not here.
-- Terry
Try changing your local TCP buffering parameters instead to allow a bigger receive window. Set DefaultRcvWindow to something like 32768; the default is 8192, which is low for a DSL line, especially one that asymmetrical. With a bigger setting, you can have more data in flight, which makes the TCP connection more tolerant of delays in ACK return.
Given the numbers you're reporting, your ACK delay isn't that severe. You're only losing 2/3 of your downstream bandwidth. So quadrupling the amount of data allowed in flight should overcome that problem. Prioritizing your uplink traffic should be unnecessary at this time.
A real question to ask is "why are you trying to run a server on a 96Kb/s line". Buy hosting from somebody; it's cheap and they'll have far more bandwidth.
You can play with these settings to get the best performance, but in general these should help out some.
c es\Tcpip\Parameters
e ntVersion\Internet Settings\
Note that, at most, simply disable then re-enable the network adapter in question. No rebooting should be required to make any of this take effect.
Keys: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Servi
GlobalMaxTCPWindowSize:DWORD = 256960
This should be a multiple of MSS, which is generally MTU - 40. Best results - pick a multiple of MSS lower than 16-bit (65535) times a scale factor that's a power of two. In other words, pick any multiple of MSS as long as it's under 65535, them multiply that by any power of two to arrive at the TCP Window size (RWIN).
Tcp1323Opts:DWORD = 1
This enables RFC 1323 options, which allows for a TCP RWIN greater than 64k. If you don't do this, most of the other settings are bunk as they will be limited by the 64k RWIN value.
EnablePMTUDiscovery:DWORD = 1
Enables automatic discovery of the MTU for your line, with the MSS set appropriately. You can set this to "0" to force your own value (see below).
TcpMaxDupAcks:DWORD = 2 (range from 1 to 3)
Number of duplicate ACKs recv'd for the same seq number of sent data before fast retrans is triggered.
NOW on to the MTU: it must be set on a per-interface basis. Find your TCP/IP interface associated with your NIC under Parameters\Interfaces\
MTU:DWORD = 1500 (probably... depends on your provider.)
On an unrelated note, you can force IE to hit up a web server with more connections than normal, which can help web pages load more concurrently.
it's under HKEY_CURRENT_USER\Software\Microsoft\Windows\Curr
MaxConnectionsPerServer:DWORD = 20
MaxConnectionsPer1_0Server:DWORD = 20
First is HTTP1.1+ servers, the other is HTTP1.0 servers. Specifies the max # of connections IE will open to a single web server in the process of downloading a page.
Natural != (nontoxic || beneficial)
If you are going to go with a linux box to do the traffic shaping just pick up an old Pentium/Pentium II from somewhere. You don't need a monitor or extra gadgets, just a box with appropriate networking capabilities. You could even borrow the mouse and keyboard from your computer to help get it up and running. Once it is all configured you should be able to just tuck it away in a nice cool place and forget about it.
"She's a West Texas girl, just like me" - G.W Bush Iraqis
If there's an other ISP that gives you high bandwidth with xDSL that does capping in a reasonable way (i.e. I'm capped at 256 kbit upstream while having 1 Mbit down) I say switch.
ADSL is duplex.
ADSL works by dividing the usable range of frequencies on your phone line into segments.
Lets say that your analogue phone line can support transmission to the local exchange of frequencies from about 0 to 1100 Khz (or there abouts) over copper. The bottom 4Khz is reserved for voice. (I dont know if voice is compressed, I suspect there is some sort of companding in action to give a wider actual response but I dont know.. but the frequency range is adequate.) Then there is a band from about 30Khz to 140 Khz that is used to support the upstream channel, and then frequencies above that out to about 1100Khz are used to support downloads. There is a gaurd band between each band that eliminates crosstalk induced by imperfect transmission conditions.
This arangement gives you 256Kbps Up and 1500kbps down. Filters are used to isolate the appropriate channels at either end for voice, upload, and download. But the point is that its duplex by design, singnals go both ways SIMULTANEOUSLY over the wire. Remember that ADSL transmission is analogue, thats why you have a MODEM (its an acronym, not a noun!)
So as has already been explained by previous posters, the most likely problem is that as you flood the upstream channel, your ACK packets are being queued, the network devices upstream then start to throttle back your downstream feed, as the ACKs are taking too long to come back. This is done to minimise the number of packets that will be dropped and resent to your address. Of course you arent dropping any packets , but the upstream devices dont/cant know that.
Anyway hope that helps. The July 2002 edition of Australian Personal Computer has a lovely graphic that explains how ADSL works and why you can use your phone and have a nice broadband connection at the same time. Unfortunately this article isnt on their site http://www.apcmag.com
Cheers
Micko
You want it cheap on windows too?
Your mission for this year:
- Become proficient in C.
- Port what you need from Linux to Windows (you suggested Linux already does everything you need).
Problem solved.
And sorry to say this, but 99% of the time this is the only way software becomes "cheap", is when someone who wants some software but can't/won't pay for it creates it (or ports it when available). Maybe you'll get lucky and it'll be ported for you, but I doubt it. Its just far easier to set up a linux router for this sort of thing.
Unfortunately, windows is well known as one of the world's biggest "pay" OSes. You just won't find much free (of consequence) for it that didn't exist on another OS first -- even taping a simple phone conversation will cost far more in software than hardware (source: The Screen Savers).
I wish you good luck on your search, though!
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
I was running this on old 386 and 486 machines with 8MB ram, though I think the newest releases require a little more ram (more ram would also allow for more firewalling rules).
T
Support TBI Research: http://www.raisinhope.org
The Wondershaper is really great. I use it on my ADSL capped at 650kbit upstream and ~475kbit downstream. Without it my ping times when uploading the full 650kbit is >500ms but with wondershaper it's 10-20ms (with a very small speed hit). Full download brings ping times around 100ms, and full speed uploads *never* hurt downloads at all.
For those interested in knowing how to tweak your ADSL, cable modem settings in Windows, the following link contains excellent and comprehensive information on how to achieve peak download speed: Navas Cable Modem/DSL Tuning GuideTM
¦ ©® ±
You might want to have a look at the following projects:
Traffic Control - Next Generation
Differential Services
GTC - A Graphical frontend the Linux kernel Traffic Control
WRR and WIP
And, yes, those are all Linux solutions, but that's simply because that' all I found available without paying 20.000 dollars.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
Increasing the window size will not change the packet size. The packets requireing retransmission will retransmitted irrespective of the window size.
There are two things he could do that might improve things, increase window size which means that the sender will not require an ACK so often or increase packet size so not as many ACKs are needed in the first place. Both may help but don't confuse them.
Zero Sum (don't amount to much). [root@localhost]
Speaseasy is my ISP and althoug its not high upload its everything else... you get fast enough down and they are what a true ISP should be... they cost a little extra but *GASP* they give linux support... call em at 3:00AM and they have a linux techie waiting for you with no wait time... even during peak hours its only maybe 5 mins to get a person on the phone... personally for me internet is more than your "up" and "down" speeds... im tired of people wanting raw kbit speed when thats not what they even really use... low latency is most of the time a bigger issue as a high down really only helps thsoe divx files come down... when your latency is low your games run smooth and the pages load faster... is 512kbit going to feel slower than 1.5mbit when its a 10k page???
unzip; strip; touch; finger; mount; fsck; more; yes; unmount; sleep
Now that's a really pathetic way to put down someone's opinion. especially when it is so ontopic.
I will so metamoderate that person into non-moderation.
Posting this at +2 again so people can read it:
ou want it cheap on windows too?
Your mission for this year:
- Become proficient in C.
- Port what you need from Linux to Windows (you suggested Linux already does everything you need).
Problem solved.
And sorry to say this, but 99% of the time this is the only way software becomes "cheap", is when someone who wants some software but can't/won't pay for it creates it (or ports it when available). Maybe you'll get lucky and it'll be ported for you, but I doubt it. Its just far easier to set up a linux router for this sort of thing.
Unfortunately, windows is well known as one of the world's biggest "pay" OSes. You just won't find much free (of consequence) for it that didn't exist on another OS first -- even taping a simple phone conversation will cost far more in software than hardware (source: The Screen Savers).
I wish you good luck on your search, though!
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Comment removed based on user account deletion
> Full use of your upstream should NOT be
> crippling your downstream so much, that's not
> how it works. TCP should adjust accordingly.
TCP normally piggybacks ACKs. That is, an ACK is sent out on traffic going the other way on the TCP connection. So, if there were only one connection, this isn't a problem.
The problem lies in asymetric TCP sessions (huge data-filled going upstream with virtually data-less ACK packets coming back) over a congested upstream link. When your upstream gets saturated, the ACKs get caught between huge packets from whatever other traffic). Cable and DSL modems, for example, have a huge queue, so it is easy for your entire TCP window of ACKs to be waiting in queue. The lack of ACKs causes the remote end of the stream to pause sending and kills your throughput.
In short, TCP is tuned for lower bandwidth links. Applications like satellite connections (where there is huge bandwidth but huge latency) could really benefit from insanely large windows, but you just don't see it much yet.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
Actually, I was quite surprised the other day. I actually used a built in modem on my laptop to dialup to check mail and download something I had to have at that moment. few megabytes download started, and I was actaully able to type over ssh link almost laglessly while the download was going at about 2.7k/second or so (this is a modem remember). And I remember on linux, if I didn't throttle the download using some download manager, things would get so laggy I had to wait like 20 seconds to see what I typed over ssh session. Surprising that the same kind of stuff doesn't work with DSL modems...