I need help with QOS

Discussion in 'Tomato Firmware' started by furyoo, Sep 28, 2006.

  1. furyoo

    furyoo Network Guru Member

    Is there any way to limit the bandwidth to web-based downloads? My reason for asking is because I share my connection with two others at home, and sometimes the Internet slows down, thanks to heavy downloading through port 80 on another computer (I found that out through Tomato, bless the firmware).

    How do I limit the bandwidth allocated to such downloads and channel more bandwidth back towards web browsing? Does inbound help at all? I tried using L7 filters for http and html but they don't seem to work at all, all the connections go through the default class (which I set as low).
  2. njeske

    njeske Network Guru Member

    you can limit bandwidth to the computer that's doing the heavy downloading. just add a QoS rule for that computer's MAC address.
  3. furyoo

    furyoo Network Guru Member

    Does that mean specifying an inbound limit? I read in the other threads that this was not advisable...
  4. NateHoy

    NateHoy Network Guru Member

    fury00 -

    It's not advisible, but the case you are looking at (downloading on port 80, presumably using HTTP) is probably one of the rare cases where it will be marginally effective.

    Basically, by "clamping down" on bandwidth provided to that address, you will get two events in rapid succession:

    1. A sudden burst of traffic and retries, actually wasting MORE bandwidth, as the HTTP download starts happening.

    2. A steady reduction in that HTTP traffic as the client computer starts receiving and acknowledging packets back to the server.

    HTTP transfers usually involve a packet or a group of packets being sent, then the client acknowledging receipt of the data using an ACK (Acknowledge) packet. The ACK packet is not sent until the data is received, and the server will not send more data until it gets the ACK packet (or a NACK, Negative Acknowledge, packet asking for a resend).

    So, when the HTTP transfer first starts, it will swamp your modem with more data than that client is allowed, and some of it will be thrown away. The client will receive a bunch of incomplete data, along with maybe a few good packets, and it will start sending ACK and NACK packets back to the server. Once the server starts getting those packets, it will start sending or re-sending data.

    For a while, the client will be still sending out a bunch of NACK packets, until it starts waiting for and receiving full and correct data. This may take a few seconds, or a minute. Once that happens, the server will be sending data as responses to ACK packets, and there will be less data loss and data throwaway, and the client and server will self-regulate (to an extent) and that client will take less bandwidth.

    It's a complete hack in terms of trying to throttle bandwidth, but since few TCP/IP clients are self-regulating or have any concept of keeping their own bandwidth demands reasonable, it's the best you can do.
  5. dankim831

    dankim831 Network Guru Member

    i think its better than nothing.

    the way i see it, either the connection will be unusable because of someone hogging bandwidth the entire time with out incoming throttling or the connection will be useless for a bit of time and then throttle back the people that are saturating it with qos leaving it useable for other users.
  6. NateHoy

    NateHoy Network Guru Member

    dankim831 -

    That's true, to an extent.

    In the case of a transaction not involving acknowledgments, the incoming packets (which are already on the router, and have taken up bandwidth) would be thrown away to no good purpose. The server will keep sending them at the fixed rate, and your ISP is throttling them based on your allocated bandwidth.

    Of course, social engineering then says that the user will likely stop trying to use applications that take up so much bandwidth, because the apps don't work. The ultimate QoS, have your users stop doing useless things that hog bandwidth in the first place. THAT'S Quality! ;)

    In the case of some protocols that send a lot of packets before expecting an ACK, the transfer might never reach the point where entire packet sets are never completely received, and the bandwidth would be hogged for a longer period of time than if you had no "inbound QoS" implemented, to no one's benefit. Basically you'd be in an "infinite retry" state, chewing up massive bandwidth all the while, and it would never end until your user gave up. Again, though, you might frustrate your bandwidth piggie enough to stop.

    But, in the average case with HTTP and other TCP applications that expect fairly frequent acknowledgments, you'll probably see more benefit than cost in the long run.

    Almost any other method will be more effective than making the router throw away packets. Many download tools have throttles that will receive the data cleanly but optimize the return of acknowledgment packets to target a given speed, so they tend to be a lot more gentle on bandwidth than having a router try to do it, and they can adjust the download speed VERY fast and VERY effectively, with little to no data loss in the process.

    However, if you have no other method, or if you have a bandwidth piggie that refuses to behave, then inbound QoS is generally better than nothing. I just wanted to set expectations properly.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice