Andrew Suffield wrote: > > Inbound is a lot harder to do, and in this setup I'm not entirely >> certain what's required. You can only shape traffic that is leaving >> an interface - you CANNOT shape traffic that is coming in. >> >> ... >> >> So what I suspect you need to do is create an Intermediate Queing >> Device (http://lartc.org/howto/lartc.imq.html). You can then apply >> the traffic shaping to traffic 'exiting' via this interface, and >> after that it can be routed out of the real interfaces. > >While this is technically possible, it doesn't address the real issue >with shaping inbound traffic: you can't actually do it.
It depends on what you want to achieve. In this case, the user wants to control bandwidth usage of a shared internet connection by several classes of user - so traffic shaping would be appropriate for this. >Outbound traffic shaping works by holding the packets in a queue, and >sending them over the shaped link at the desired rate - this does >exactly what you expect, controlling the rate of traffic over the >link. But ultimately that queue is limited in size - so either the incoming traffic slows down or packets are lost. See below ... >Inbound traffic shaping occurs *after* the traffic has already moved >over the link you're trying to shape. It is already too late to >control the rate at which these packets have moved. The mechanism used >to create the appearance of inbound traffic shaping is to selectively >degrade the reliability of the link: the inbound shaper drops packets >on the floor, and hopes that the remote system interprets this as the >link being overloaded, and slows down the rate at which it is sending >packets in the future. In the case where the remote system is a >well-behaved TCP application (such as a typical web server), this will >work. In the case where it's some game or VoIP system using its own >UDP-based traffic management, it probably won't. Which is why I am moving away from just randomly dropping packets on the floor, and prioritising which ones I drop - for example not dropping VoIP packets. If your UDP traffic is exceeding bandwidth, then some "user education" is probably called for ;-) >Against a hostile >system that is attacking you, it is completely worthless. Is anything - without some fairly "high end" gear ? >And never forget that inbound traffic shaping is always deliberately >making your link unreliable: packets will be lost. This can cause more >problems than it solves; it wrecks most VoIP systems, rather than >improving them. As mentioned above, the (partial) answer to that is to not drop your VoIP packets ! If you shape to below line speed, then the upstream buffers will mostly be empty. In that situation, you can tolerate bursts although a large burst will increase latency & jitter until the upstream buffer empties again. The more you throttle your traffic below the available link speed, the better the approximation. In our case, we have a 6mbps line, but the actual fibre connection is 10mbps and the 6m limit is imposed by a Cisco router at the other end of the link. Using one online speed checker, we register 7m upstream because the checker doesn't run long enough to exhaust the burst the router is obviously configured with, and on the downstream test, you can see it jump up to over 7m and then settle down to 6. I agree that you cannot completely do the job at the receiving end, but you can do a fairly good approximation with a little care and given the right circumstances. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
