Hi Guys, Here is a question that is probably of concern to many of us. I am under pressure to provide some solution for ingress traffic shaping. What my customer demands is to divide the downstream (ingress) of an ADSL lines to two classes of traffic - important traffic and non important downloads. He has a very reasonable requirement: he wants a guarantee of at least 1000kbps at all times for the important traffic on the downstream. Using ingress policing would be the trivial solution. But no says the customer - when the important traffic is not fully utilizing its rate, I want it to share the excess with other classes. After looking around, the answer I found was to use imq, which claims to allow traffic shaping on ingress traffic. So far so good. And now I arrive to the question: It is possible to configure everything in THEORY. The question is, it it really possible for me to give the guarantee that my customer is asking for? I can think of examples why it seems that the answer is no. For example, lets say the ingress line is completely saturated with non-important traffic. How on earth can the poor HTB determine whether important traffic is being drowned out - or there is simply no important traffic? My speculation so far - it is possible to configure these rules, and indeed this is what IMQ was invented for, but in true life there is no solution that works - since it is inherently impossible! Has anyone really created and tested a working ingress traffic shaping solution? Aron
On Monday 19 January 2004 14:19, Aron Brand wrote:> Hi Guys, > > Here is a question that is probably of concern to many of us. > > I am under pressure to provide some solution for ingress traffic > shaping. What my customer demands is to divide the downstream (ingress) > of an ADSL lines to two classes of traffic - important traffic and non > important downloads. He has a very reasonable requirement: he wants a > guarantee of at least 1000kbps at all times for the important traffic on > the downstream. > > Using ingress policing would be the trivial solution. But no says the > customer - when the important traffic is not fully utilizing its rate, I > want it to share the excess with other classes. > After looking around, the answer I found was to use imq, which claims to > allow traffic shaping on ingress traffic. So far so good. > > And now I arrive to the question: It is possible to configure everything > in THEORY. The question is, it it really possible for me to give the > guarantee that my customer is asking for? I can think of examples why it > seems that the answer is no. For example, lets say the ingress line is > completely saturated with non-important traffic. How on earth can the > poor HTB determine whether important traffic is being drowned out - or > there is simply no important traffic?It can, but it will take some time before the non-important traffic will slow down.> My speculation so far - it is possible to configure these rules, and > indeed this is what IMQ was invented for, but in true life there is no > solution that works - since it is inherently impossible!It''s impossible because you can never control what people send to you. Tcp will throttle down if there is less bandwidth, but this can take some time. So you can only hope the other side will stop sending packets if you drop packets (I try the same with spam but it''snot woring :( )> Has anyone really created and tested a working ingress traffic shaping > solution?You don''t need imq for this. If you put a router (or bridge) between the ADSL and the LAN, you can shape on both interfaces. So the LAN interface can be used to shape incoming traffic. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi Stef, Thanks for the helpful information. What do I need to set as the line rate for the LAN side shaper? I assume that if I want it to work it must be slower than the real downlink speed - is this right? Are there recommended values - such as 10% lower than the real downlink speed? I am wondering, has anyone done any benchmarks that indicate how accurate is shaping of TCP streams in the inbound direction? For example, say that during peak periods the customer wants to enforce 20% of the traffic to web and 80% to FTP downloads, how long will it take until it stabilizes on these rates? And how accurate can I expect it to be? Thanks, Aron -----Original Message----- From: Stef Coene [mailto:stef.coene@docum.org] Sent: Monday, January 19, 2004 8:28 PM To: Aron Brand; lartc@mailman.ds9a.nl Subject: Re: [LARTC] Ingress Shaping using IMQ On Monday 19 January 2004 14:19, Aron Brand wrote:> Hi Guys, > > Here is a question that is probably of concern to many of us. > > I am under pressure to provide some solution for ingress traffic > shaping. What my customer demands is to divide the downstream > (ingress) of an ADSL lines to two classes of traffic - important > traffic and non important downloads. He has a very reasonable > requirement: he wants a guarantee of at least 1000kbps at all times > for the important traffic on the downstream. > > Using ingress policing would be the trivial solution. But no says the > customer - when the important traffic is not fully utilizing its rate,> I want it to share the excess with other classes. > After looking around, the answer I found was to use imq, which claims > to allow traffic shaping on ingress traffic. So far so good. > > And now I arrive to the question: It is possible to configure > everything in THEORY. The question is, it it really possible for me to> give the guarantee that my customer is asking for? I can think of > examples why it seems that the answer is no. For example, lets say the> ingress line is completely saturated with non-important traffic. How > on earth can the poor HTB determine whether important traffic is being> drowned out - or there is simply no important traffic?It can, but it will take some time before the non-important traffic will slow down.> My speculation so far - it is possible to configure these rules, and > indeed this is what IMQ was invented for, but in true life there is no> solution that works - since it is inherently impossible!It''s impossible because you can never control what people send to you. Tcp will throttle down if there is less bandwidth, but this can take some time. So you can only hope the other side will stop sending packets if you drop packets (I try the same with spam but it''snot woring :( )> Has anyone really created and tested a working ingress traffic shaping> solution?You don''t need imq for this. If you put a router (or bridge) between the ADSL and the LAN, you can shape on both interfaces. So the LAN interface can be used to shape incoming traffic. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 20 January 2004 15:05, Aron Brand wrote:> Hi Stef, > > Thanks for the helpful information. > > What do I need to set as the line rate for the LAN side shaper? I assume > that if I want it to work it must be slower than the real downlink speed > - is this right? Are there recommended values - such as 10% lower than > the real downlink speed?It depends. But try 10% and measure the link usage.> I am wondering, has anyone done any benchmarks that indicate how > accurate is shaping of TCP streams in the inbound direction? For > example, say that during peak periods the customer wants to enforce 20% > of the traffic to web and 80% to FTP downloads, how long will it take > until it stabilizes on these rates? And how accurate can I expect it to > be?It can be very accurate and very fast. Like said before, it depends on the software you use and how quick to software reacts on a change in the bandwidth. I did some bursts test with htb. You can see on some of the graphs that if there is an other tcp stream, htb reacts very fast. But this only for outoing packets and measered on the loopback interface. So the problem is not htb, but application, routers, modems, ... http://docum.org/stef.coene/qos/tests/htb/burst/ Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/