Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Traffic Shaping on DSL? 368

Posted by Cliff from the applying-your-own-bandwidth-throttle dept.
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)
This discussion has been archived. No new comments can be posted.

Traffic Shaping on DSL? More

Traffic Shaping on DSL?

Comments Filter:

  • What are you running? (Score:5, Interesting)

    by secondsun ( 195377 ) <secondsun@gmail.com> on Thursday July 18, 2002 @09:51PM (#3913786) Journal
    Are you a server, business or home user? I understand that you want as much bandwidth as possible, but if you are just a home user, 400 kbit down stream is not bad at all.

    To answer your question directly, my solution would be to buy a cheap box (like say, the Mandrake boxes from Wal-Mart) and use it as your traffic shaper. Linux products for this are much cheaper than any (useable) solution you can find for windows.

    • Re:What are you running? (Score:4, Insightful)

      by DrVxD ( 184537 ) on Thursday July 18, 2002 @09:59PM (#3913838) Homepage Journal
      > 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.
      • Maybe he should look into switching ISP's. The cool thing with *DSL is that you actually have a choice about who your ISP is. Take the sitation where I live in .nl for example, where cable internet is restricted to one ISP that can totally screw you over and leave you groaning and paying the bill. Signing up for DSL is the perfect way to give those scamming crappy cable ISP's the middle finger and to tell them to stick their cable where the sun don't shine. But that's just the situation here in the low lands. I am digressing...

        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.

        • Speaseasy [speakeasy.net] 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???
          • Aye low latency and a FLAT router path to the backbone.

            Do a tracert and see how many hops you make...

            Try looking at an SDSL connection and solve the asymetric problem :)
        • It's not his ISP. Until a recent upgrade to faster DSL (I haven't had it long enough to get a feel for it yet), I had 1.5M/128K DSL, and full-speed uploads using Hotline would completely hose other connections. Before that I lived where I could only get 384K/128K, and full speed downloads could completely choke the connection too.

          One of my objectives now is to look for servers (ftp, http, etc.) which can inherently limit stream speed, but the "prioritize ACKs" suggestion by the submitter sounds like something I can do with ipchains/ipfilter on my router server after some quality time with TFM.

      • 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.

        I don't know of ANY DSL providor that garauntees 1.5Mbit (you probably meant mbit). All of the ads that I see say "up to 1.5mbps". Depending on his distance from the CO it might be a good speed.

        • I don't know of ANY DSL providor that garauntees 1.5Mbit (you probably meant mbit). All of the ads that I see say "up to 1.5mbps". Depending on his distance from the CO it might be a good speed.

          Telstra in australia will not give you an aDSL line if when tested it can not reach 1.5Mbps.
          Which is a bit of a pain, as no 1.5Mbps, no aDSL.

          Moves are afoot by InterNode (another .au ISP to get Telstra to change this to something lower, so that people can still get service even if they can't get 1.5Mbps). As all aDSL work is done by telstra (they pretty much own the last mile of copper in .au) they effectively can do what they like.

          BTW by poking around my alcatel modem , it tells me that my line is good for max of around 6.8Mbps downstream to me. I know someone mentioned once that in Hong Kong they could get 6Mbit / 1Mbit adsl connections for relatively cheap. Bastards.

          (Oh, btw it should be big M , for Mega, little m is milli)

    • 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.

  • I don't get it... (Score:2, Insightful)

    by neksys ( 87486 )
    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*
    • i also have a similar cap and run my website (down for a week weeks while i try and get tyan off their asses) off the line. this means i average a loaded 128kbits going out, but i can easily download at blazing fast speeds. i think your problem lies in hardware as well.

      maybe your provider directly hacked the modem they gave you, or your ethernet card or router isn't good at handling up and down traffic at once.

    • Re:I don't get it... (Score:3, Interesting)

      by TFloore ( 27278 )
      Don't know if it is his provider or his hardware, but my cablemodem connection does the same thing. And it seems to be dependent on the cablemodem hardware.

      When I first got my cablemodem connection, it was with an older hybrid cablemodem. Got about 1.8mbit/sec downstream, and about 500kbit/sec upstream, and I could use all of that upstream and it didn't affect my downstream at all.

      About a year after signing up for the cablemodem, my ISP "upgraded" their network, and I got a new cablemodem. DOCSIS 1.0 (1.1?) 3Com USRobotics Cable Modem CMX. It maxed out at about 2.2mbit/sec downstream, but only about 256kbit/sec upstream, and now, when I use all of the upstream, my downstream drops to about 350kbit/sec. (I say "maxed" because I think they dropped the max downstream to about 1.5mbit/sec 6 months ago, a year after I got the new cablemodem.) The computer connected to the cablemodem did not change at all, so this was purely from the cablemodem change.

      So I would also be interested in something that can prioritize the packet ACKs, since the cablemodem doesn't seem to do it itself anymore.

      I do tend to regard this as a hardware issue with the cablemodem. From reading this, you can probably understand why.

    • Lots of people complain about this.... (Score:5, Informative)

      by billstewart ( 78916 ) on Thursday July 18, 2002 @10:42PM (#3914095) Journal
      There are a couple of problems that can lead to this symptom, and asymmetric connections are more likely to suffer from it. Basically, if your upstream bandwidth is swamped with file transfers, it's hard for the ACKs for packets you receive on your downstream to get through, so the downstream TCP sessions get throttled. Many DSL providers oversubscribe their links (though the problem is usually worse downstream than upstream)(cable can have this problem also), so that 128kbps upstream you thought you had might only be 38kbps if lots of people are uploading at the same time - so your upstream packets may be queued at the DSLAM, and your little ACK packets have to wait for a windowful of big file transfer packets to clear out, or they may be queued in _your_ DSL router. An 8KB TCP window is 80k bits, so even if you're getting your whole 128kbps upstream, that's over half a second of data that could be sitting ahead of your ACK, dogging your downstream flow rate. It's especially bad if your upstream traffic has a big window size, while your downstream is using slowstart and has never gotten a very big window.

      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.

  • Router-on-a-disk (Score:3, Informative)

    by DrVxD ( 184537 ) on Thursday July 18, 2002 @09:55PM (#3913809) Homepage Journal
    LRP [linuxrouter.org]'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.
  • Sorry if this is a stupid question - Why would 70kb/sec upstream utilization reduce downstream bandwidth by nearly 1Mb/sec? That makes absolutely no sense to me, but then again, I'm not a Network Engineer. Can anyone more knowledgable explain this?

    • I can't explain it, but the same thing happens to me. Its like, if I'm using 90% of my upload bandwidth (128 kbit), I only get 10% of my download bandwidth (1.5 mbit). Its very annoying. I would be intersted in something like this for windows as well (I find it too annoying to reboot whenever I want to play a game)

    • Re:Huh? (Score:3, Informative)

      by 1010011010 ( 53039 )
      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.

      • Re:Huh? (Score:3, Insightful)

        by BurritoWarrior ( 90481 )
        Couldn't he reduce the number of ACK's by increasing his window size?

        • Re:Huh? (Score:3, Insightful)

          by Anonymous Coward
          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.

          • Re:Huh? (Score:2, Informative)

            by Anonymous Coward
            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...

          • Re:Huh? (Score:3, Informative)

            by Zero Sum ( 209324 )
            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.

            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.

    • The 70k (or whatever) upstream limit is based on actual bits transmitted across the network - including protocol bits. Since the 1M/sec downstream traffic has a certain amount of handshaking back to the source of the data, that handshaking has to travel back as part of the 70k upstream. If the handshakes don't get, then the downstream can slow or resend (net effect is a slowdown of actual throughput).
      Does that make sense? I know what I mean, but I don't think I'm communicating it very well :-(

      • Re:Huh? (Score:2, Informative)

        by marcushnk ( 90744 )
        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?

    • Re:Huh? (Score:3, Informative)

      by Anonymous Coward
      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
    • Sorry if this is a stupid question - Why would 70kb/sec upstream utilization reduce downstream bandwidth by nearly 1Mb/sec? That makes absolutely no sense to me, but then again, I'm not a Network Engineer. Can anyone more knowledgable explain this?

      IAANE... here's why: TCP is always transferring data in both directions, even if you're only downloading. When your upstream link is full, you can't send acknowledgements of the data you're receiving downstream. These lost "ACKs" tell the transmitting side that somewhere along the path there is a saturated link, but it doesn't know in which direction they're being dropped. The transmitter will back off his data rate to try and reduce the packet loss, and this is what causes your slower throughput.

    • Re:Huh? (Score:2, Interesting)

      by leo_fischer ( 594217 )
      I believe that it is due to ADSL's asymmetric nature. An ADSL connection has an upstream and downstream speed, such as 1.5MBps vs 128kbps. I think the connection is NOT duplex, so when you are sending upstream, you cannot be recieving downstream. So if you upload at 64kbps, you are effectively using HALF your bandwidth, limiting your downstream speed to 750kbps. i.e. if you are transmitting half the time, you can only recieve half the time. So if you use too much of your upstream bandwidth, you can bring the downstream to a crawl.

      • ADSL is DUPLEX (Score:3, Informative)

        by El Micko ( 118401 )
        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 [apcmag.com]

        Cheers
        Micko
        • Remember that ADSL transmission is analogue, thats why you have a MODEM (its an acronym, not a noun!)

          Yeah, I always found it amusing that ADSL is no more of a "digital subscriber line" than my POTS line running a 2400 bps modem. Now ISDN and SDSL lines, I'd consider digital with their 2B1Q modulation.

  • Build a Linux box, use QoS and cbq.init (Score:4, Informative)

    by fialar ( 1545 ) on Thursday July 18, 2002 @09:57PM (#3913828)
    My recommendation, keep that Windows box behind the firewall box (let the fw box NAT for it). Run Linux or BSD on the firewall box.

    If you're using Linux on the firewall machine, make sure you enable QoS and ALL the modules in it. Then grab cbq.init [sourceforge.net] and set up the traffic shaping rules. The script file is well documented.

    -F-

  • Packet Scheduler (Score:1, Informative)

    by tbaggy ( 151760 )
    Instead of sarcastic comments about "run linux" "format c:" blah blah, check out this [microsoft.com] kbase entry from MS regarding the packet scheduler. It might be useful to you.

    • Re:Packet Scheduler (Score:5, Informative)

      by bogie ( 31020 ) on Thursday July 18, 2002 @10:21PM (#3913989) Journal
      Unfortunatly this won't help him. The QOS packet service is designed primarily for audio/video applications and would require that every router he connected through strictly obeyed the 802.1p protocol. That is just not going ot happen.It also requires a heck of a lot more then just clicking that little check box on the XP client. You can just consider that an on/off switch, the real work is done at the server and endpoint router levels.

      Have a look at this link for some futher explaination. http://infocenter.cramsession.com/techlibrary/geth tml.asp?ID=1674

    • I forgot to add-

      In this case "run linux" or more appropriatly, run an additional machine that runs linux would be in all likelyhood the right answer for this situation. Other options are probably way too expensive.

    • Re:Packet Scheduler (Score:2, Insightful)

      by fermion ( 181285 )
      So how is this any better? The question is traffic-control on my Windows XP box... not, as you say, linux box, or even the windows 2000 box in this KB article.

      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?

  • and you won't have a problem with downstream traffic :)
  • What are you using your upload bandwidth for? Many windows programs, such as ServU FTP server, allow you to cap your upload speeds.

    Otherwise, perhaps something like this [com.com] would be better for you.

  • DSL Reports... (Score:5, Interesting)

    by Jeffv323 ( 317436 ) on Thursday July 18, 2002 @10:02PM (#3913862)
    ... has a Tweak Test [dslreports.com] that tests some connection settings such as your RWIN. I had the exact same problem as you and it turned out that my RWIN was set wrong and once I fixed it, the problem pretty much went away. Try it and I bet it helps.

  • Linux.... (Score:2, Informative)

    by I_am_Rambi ( 536614 )
    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!

  • first thing to find out is.. (Score:4, Informative)

    by trybywrench ( 584843 ) on Thursday July 18, 2002 @10:06PM (#3913889)
    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'd take a wild guess that he's running some sort of P2P client (e.g. KaZaA [kazaa.com], Direct Connect [neo-modus.com], Gnutella [gnutella.com] etc.) They can soak up a lot of upstream bandwidth (so I've heard :-)
      • Well, of all of the recent P2P clients out there (that I have looked at), they all have bandwidth throttling built-in. Any decent ftp server has throttling built-in as well. FYI: Napster did not have bandwidth throttling, which I bet is the number one reason why many people didn't let it run 24/7.

        Moving on...

        After reading some of the comments here, I'm surprised to see so many people posting comments whom are confused by this person's problem.

        Experiencing slow web-browsing or slow downloads when upstream is saturated, despite having significantly adequate downstream, is easily explainable. The big picture is that servers are not going to send you more pieces of the file/webpage until you confirm that you received the last piece it sent to you. If your upstream is saturated, you cannot send that confirmation back as quickly, and the server is then simply waiting for you to "ask" for more

  • Already There (Score:3, Informative)

    by BurritoWarrior ( 90481 ) on Thursday July 18, 2002 @10:06PM (#3913891)
    I believe XP comes with the "QoS Packet Scheduler" and has it installed by default. I believe it can do what you ask.

    • Nope. (Score:4, Informative)

      by mindstrm ( 20013 ) on Thursday July 18, 2002 @10:31PM (#3914039)
      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.

  • Dummynet (Score:4, Informative)

    by seanadams.com ( 463190 ) on Thursday July 18, 2002 @10:09PM (#3913906) Homepage
    Could such a traffic shaper be built using low powered computers?

    Fire up that 90MHz Pentium, install FreeBSD [freebsd.org], 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?

  • OpenBSD (and a few of the other BSDs, I believe) has great support for ALTQ (alternate queuing) which does precisely what you want. (It's what I use it for).

    Go here [sony.co.jp] for ALTQ.

    And here [agenteight.com] is my altq.conf, if you're curious.

  • I don't see what you are getting at.

    Rather, I think I see what you are getting at, but I think the assumption is flawed.

    Full use of your upstream should NOT be crippling your downstream so much, that's not how it works. TCP should adjust accordingly.

    • My router (Netgear RT314) has a telnet screen that displays through (Tx & Rx). I haven't checked with my new 1184/160 G.Lite DSL connection, but with my old Nortel (unknown standard) 960/120 I saw this problem. When I was downloading at full speed (105kB/s), I saw 3-4kB/s upstream activity, which was in excess of 20% of the upstream bandwidth. No wonder that fast uploads choked concurrent downloads. I increased my RWIN, but I don't want it above 32K. Unfortunately, this didn't have much affect.

      I think the situation is made worse when the DSL line is set for interleave rather than fast path. On my line, the first hop latency with interleave path is about 70ms, and fast path it is about 10-15ms. I know this because my telco recently tried to switch me over to fast path, which resulted in 40% packet loss due to a higher communication error rates with the modem and the other end (DSLAM port?) at the CO.

      This excellent paper [www.cwi.nl] (PostScript format) describes some of this, and in particular, interleave path vs. fast path.

    • TCP (Score:2, Informative)

      by KagatoLNX ( 141673 )
      > 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.

  • Having same problem I've attempted to use
    ALTQ with openBSD. It did not work since
    they do not work well on slow speeds (below
    8Kb/sec).

  • 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 [luxik.cdi.cz] 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 [luxik.cdi.cz].

    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
    • One floppy Linux distro that I've used with good results is Coyote Linux [coyotelinux.com]. Its based on the LRP, boots from one floppy and can do Masq'ing. You can even build a custom kernel to include the QOS stuff, so long as there is enough space on the disk. Once booted, it gives you a basic text menu for information and configuration. iirc it requires a Linux box to setup the distro and write the floppie, but that may have changed.

      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

  • When I was designing support for discarding packets in a BRAS (Broadband Remote Access Server), I put in support to prioritize control packets (i.e. tcp ACK over data packets to try and make this a lot better. A BRAS is a box that sits at the other end of a DSL modem and terminates PPP and PPPoE sessions (and more). This would only affect traffic going to the end user since the upstream traffic is usually shaped in the modem. I put this in specifically to deal with the problem you describe. I ran into the same problem when @Home reduced the upstream bandwidth to 128Kbps from 1Mbps. I did some shaping on the software running on my computer which helped a lot, but most users don't have that flexibility.

    The box I'm working on supports tens of thousands of simultaneous DSL users and can shape and buffer each user's traffic independently, going so far as being able to shape individual traffic flows to and from a user. It's also designed so that a user can change the amount of bandwidth they want on the fly and letting the ISP choose how to charge for this. This also allows for things like downloading video on demand, where the pipe from a video server to the subscriber can guarantee bandwidth for that flow.

    As for shaping traffic in Windows? I havn't a clue. I don't do Windows.

  • Bandwidth Limiting HOWTO (Score:5, Informative)

    by dimator ( 71399 ) on Thursday July 18, 2002 @10:33PM (#3914049) Homepage Journal
    Bandwidth Limiting HOWTO [tldp.org] might be of some assitance? Or not... either way. It just caught my eye on linuxdoc.

  • Okay, here's the issue. I've set this up myself, and there are good HOWTOs on it, and I've done a bit of testing. First, the problem is not prioritization. The packets are leaving the XP box in perfect order. The problem is that the cable modem has a ridiculously large upload queue, which fills up. Packets then take a hell of a long time to get through. You just want to cap the outgoing data rate *at your computer* to just below the cable modem limit, which keeps the buffer from filling up. You can play with prioritizing various packets if you want, but it doesn't do much of anything for me. The data rate cap massively improves download rate.

    Honestly, I'd just get an old box and set up a nice Linux router/mail server/whatnot, which will give you more flexibility and if you decide to add more machines to the network, not require you to have your workstation up 24/7.
  • This could be an interesting feature to add to their already EXTREMELY USEFUL "Cable/Dsl Routers"

    Linksys managers listening??? Get your engineers working on it.

    Linksys recruiters listening??? I have several other ideas that would be nice to incorporate and since I'm a college student I'd rather not give them away for free :)
    • Linksys has a broken PPPoE client in their routers - they do not ensure that all packets are greater than the Ethernet minimum size. See http://www.istop.com/linksyssucks.html for the details.

      Personally, I'm running an SMC Barricade 7004ABR, and love it.

  • BBIAgent (Score:5, Informative)

    by t0qer ( 230538 ) on Thursday July 18, 2002 @10:53PM (#3914150) Homepage Journal
    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
    • Whoa, that is COOL! Just checked out and played with BBIagent.... and that is the freakin' best little web-managed firewall system I've seen to date. Wow.

      Though I won't use it myself (i've become pretty skilled with the BSD pf), I know a ton of people who will absolutely love this. Absolutely awesome. Thank you for posting this!

  • You aren't going to be able to fix this locally (Score:5, Informative)

    by tlambert ( 566799 ) on Thursday July 18, 2002 @10:57PM (#3914169)
    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

    • Re:You aren't going to be able to fix this locally (Score:5, Insightful)

      by Malor ( 3658 ) on Friday July 19, 2002 @01:11AM (#3914702) Journal
      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.

      • Run the numbers. (Score:5, Insightful)

        by tlambert ( 566799 ) on Friday July 19, 2002 @03:18AM (#3915069)
        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
    • I have a traffic shaper running in my linux router box right here. Works like a charm. The important thing is that you can have two or more priority classes. Higher one for ACK packets and slower one for "bulk" traffic. So ACK packets still do not fill up your upstream buffer, but they'll always get preference over data packets. You can read all about it in the linux traffic shaping howto (http://lartc.org/).

      You might think this is a one-stop solution for running P2P-apps unfairly, i.e. with extra slow upstream quota. Unfortunately, edonkey etc keep on opening new upstream connections since they think there's still plenty of bandwith to spare.. 20-odd rate-limited upstream connections is bad for your karma :-)

    • Re:You aren't going to be able to fix this locally (Score:5, Insightful)

      by joe user jr ( 230757 ) on Friday July 19, 2002 @02:16AM (#3914909)
      Nope. It may well work to apply a fix at the local end. It all depends on what actual traffic is causing the problem

      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).

    • So much disinformation (Score:4, Interesting)

      by Nicolas MONNET ( 4727 ) <nicoaltiva@gmai l . c om> on Friday July 19, 2002 @04:50AM (#3915291) Journal
      The latency is -- most likely -- caused by the huge buffers in the modem. It *is* possible to improve the situation locally. It's got nothing to do with asymetric lines or somesuch.

      It's simple: what happens is that the upstream buffer in the DSL modem does'nt prioritize traffic at all, most likely it's just FIFO and big. So if the buffer is 128kB and you're serving a big file, your next Telnet packet is going to have to wait for these 128kB to go up before going itself.

      The solution: have a router that artificially limit the outgoing bandwidth to slightly less that the DSL line permits to make sur the modem's buffer never fills up. Then it's the router's buffers that are filling up; but your router is smarter and you can have it order packet. IE if you have 128kB worth of warez0r waiting to go up, it can decide to let that lone Telnet packet go first.

      Me I installed Wonder Shaper [lartc.org], works very well esp. when you've identified what causes the contention (just add the relevant ports to the junk traffic list), even if I completely saturate the link. There's one thing that doesn't work tho: I discovered that at times I had huge ping, again, even with wshaper. What happens (*I think*) is that my ISP is getting overloaded at times, and my actual bandwidth goes below what I set it to in Wshaper. I have to find a way to improve this.

  • Collisions? (Score:2, Interesting)

    by LinuxWhore ( 90833 )
    I dunno. When I hear stuff like this is think of what happens when you start running traffic through a full-duplex NIC on a half-duplex LAN. If a full-duplex machine on the network starts sending/recieving traffic from the net, it's gonna seriously affect your throughput. I always suggest that people check through all their machines for full-duplex OR 100Mbit when using a 10M hub or a low-end 10/100 switching hub.

  • Just change the TCP maximum receive window (Score:5, Informative)

    by Animats ( 122034 ) on Thursday July 18, 2002 @11:19PM (#3914257) Homepage
    OK, let's look at what's going on here. The downlink is being underutilized when the uplink is saturated. That just looks to TCP like a link with a long round-trip time, which TCP can handle. But the Windows default configuration isn't set up for it.

    Try changing your local TCP buffering parameters [microsoft.com] 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.

    • The problem is outbound pool retention time.

      Making the receive window larger is going to delay the amount of time before an ACK is mandatory, not reduce the contention once an ACK becomes necessary.

      In other words, if I'm filling a bucket a 10 gallons a minute and emptying it at 1 gallong a minute, no matter how big you make the bucket, it's going to overflow eventually.

      In other words, your outbound ACKs are still going to have to stand in line behind your outbound data at the outbound rate limiting box.

      I will now point out that every outbound buffer between you and the rate limiter will also be full, and need to drain before your ACKs get through...

      -- Terry

  • Setting up Win2K/XP for broadband (Score:5, Informative)

    by rabtech ( 223758 ) on Thursday July 18, 2002 @11:28PM (#3914290) Homepage
    You can play with these settings to get the best performance, but in general these should help out some.

    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\Servic es\Tcpip\Parameters

    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\Curre ntVersion\Internet Settings\

    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.

    • EnablePMTUDiscovery:DWORD = 1
      Enables automatic discovery of the MTU for your line, with the MSS set appropriately.
      note: Path MTU discovery is about discovering the MTU of the PATH, not the line. If you disable path MTU discovery, and make a connection to somewhere that has a lower MTU than 1500 (used to be most of the Internet, now it's rather few places), your packets will be broken up by the intermediate routers, and performance will suffer.
      In some cases, due to stupid firewalls, path MTU discovery doesn't work, and the connection will just hang. That's the time you need to finagle this value.
  • Currently I have a 128K/128K connection, I wont let the family touch the idsl when Im playing games. But if there was a way I could limit them to like 24K MAX during my games, I could get away with it.

    Anyone know if this will help on a low speed dsl?

  • Use your support (Score:2, Interesting)

    by orasio ( 188021 )
    I believe you are using a commercial OS, so there must be a way they can help you. At least I think a great support system must be reason you are paying for your OS, isn't it?

    Good luck

  • Best Solution (Score:2, Informative)

    by shepd ( 155729 )
    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!

    • Offtopic? (Score:2, Informative)

      by shepd ( 155729 )
      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!
  • I have pretty much the same problem, and it looks from the posts so far that there isn't any existing solution to do queueing/shaping on XP... Does anyone know where to look for documentation for how you would write a program to do this? What API do windows software firewalls use to intercept packets? I've looked around MSDN a bit, but didn't find anything, is there an unofficial guide somewhere?

    --
    Benjamin Coates

  • ADSL tweak guide... (Score:4, Informative)

    by frleong ( 241095 ) on Friday July 19, 2002 @03:20AM (#3915073)
    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 [att.net]

  • Some Trafic Shaping Solutions: (Score:3, Informative)

    by AftanGustur ( 7715 ) on Friday July 19, 2002 @03:29AM (#3915110) Homepage


    You might want to have a look at the following projects:

    Traffic Control - Next Generation [sourceforge.net]

    Differential Services [sourceforge.net]

    GTC - A Graphical frontend the Linux kernel Traffic Control [sourceforge.net]

    WRR and WIP [sourceforge.net]

    And, yes, those are all Linux solutions, but that's simply because that' all I found available without paying 20.000 dollars. [packeteer.com]

  • Simple solution (Score:2, Interesting)

    by terminal.dk ( 102718 )
    You don't need traffic shaping. Just make sure your TCP receive buffer size is 15 time larger than your TCP transmit buffer size, and the ACKs will be sent in a timely manner.

    Works perfectly for me. Disadvantage is, that this is a setting you must set on all machines.
  • He's running an fserv on irc.. His problem is he can't download pr0n fast enough while sending enough to meet his quota.

  • Get a Linux router (Score:3, Interesting)

    by Pedrito ( 94783 ) on Friday July 19, 2002 @07:33AM (#3915537)
    Like others said, get a cheapo box throw two ethernet cards in it, load Linux, and use it as a router. I have this setup myself, along with 4 Windows machines behind it.

    Believe me, I sleep better at night, knowing that I have Linux between the Internet and my Windows boxes. There are a number of good firewall/proxy/router tools for Linux. You can then use the traffic shaping software, and more importantly, you don't have to worry about the constant security weaknesses found in Windows that make your machine an easy target for hackers.
  • 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...

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close