I would like to differentiate incoming traffic streams to guarantee minimum bandwidth to some services. However, as per the Adv-Routing-HOWTO it appears that only outgoing traffic can be shaped. Is this correct or is there a way of shaping incoming traffic? The problem could possibly be overcome if there is a way of routing traffic through a virtual host. Any tips on how to go about that? -- Manfred
It is nerly FAQ. You can use Ingres qdisc to do it and attach policers here. It would be nice to be able to attach every qdisc to incoming interface but it is not possible. There is always problem - when packet already hitted your box why do you want to drop/delay it ? You should to do it on outgoing side of link to your box .. When you are router (not app box) then you can shape both directions. On your virtual-host note. I already did patch (called IMQ) which implements virtual inteface allowing to attach single qdisc to multiple outgoing devices. It should be relatively easy to extend it to catch incoming packets too - only there is no time to do it. best regards, devik On 19 Nov 2001, Manfred Bartz wrote:> > I would like to differentiate incoming traffic streams to guarantee > minimum bandwidth to some services. However, as per the > Adv-Routing-HOWTO it appears that only outgoing traffic can be shaped. > Is this correct or is there a way of shaping incoming traffic? > > The problem could possibly be overcome if there is a way of routing > traffic through a virtual host. Any tips on how to go about that? > > -- > Manfred > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > >
Martin Devera <devik@cdi.cz> writes:> It is nerly FAQ. You can use Ingres qdisc to do it and attach > policers here.Ah ok, I found the SYN flood example in the HOWTO. :) But that seems to work by dropping packets rather than queueing them, which is not so good if your bandwidth is very limited (modem dialup).> It would be nice to be able to attach every qdisc to incoming interface > but it is not possible. There is always problem - when packet already > hitted your box why do you want to drop/delay it ?Because some of the traffic is for this box (doesn''t go out) and I don''t want it to ``steal'' all the bandwidth from traffic that is forwarded through the box. Also, the traffic is mostly asymmetric, lots of data coming in and only ACKs going out.> On your virtual-host note. I already did patch (called IMQ) which > implements virtual inteface allowing to attach single qdisc to multiple > outgoing devices.Could you post the URL for that?> It should be relatively easy to extend it to catch incoming packets > too> - only there is no time to do it.Hmm, lack of time is a universal problem me thinks... ;) -- Manfred
On Mon, Nov 19, 2001 at 12:21:19AM +1100, Manfred Bartz wrote:> > I would like to differentiate incoming traffic streams to guarantee > minimum bandwidth to some services. However, as per the > Adv-Routing-HOWTO it appears that only outgoing traffic can be shaped. > Is this correct or is there a way of shaping incoming traffic?"Shaping" of incoming traffic would only (if anything) have an effect on applications that received that traffic and/or CPU usage, it wouldn''t change whether or not packets got to you. The problem is that by the time the packet is in the shaping routine, it has already inherently passed your network interface. At that point, it had already passed your ISP''s router and any limitations they have on your incoming traffic (like speed caps, etc.). If your interface was fully congested or your incoming bandwidth is saturated at the ISP link, the ISP would be dropping/queuing packets, not you. If you are experiencing incoming network congestion (packets are out of order during high usage times is a good indicator), then ask your ISP if they will shape the traffic to you based on your preferences. -- Michael T. Babcock CTO, FibreSpeed Ltd.
At 01:17 2001-11-19 +1100, you wrote:>Martin Devera <devik@cdi.cz> writes: > > > It is nerly FAQ. You can use Ingres qdisc to do it and attach > > policers here. > >Ah ok, I found the SYN flood example in the HOWTO. :) >But that seems to work by dropping packets rather than queueing them, >which is not so good if your bandwidth is very limited (modem dialup).On the contrary, a well behaved traffic stream adapts to the speed of the weakest link. Dropping packets in a TCP stream will cause the sender to slow down. This is how TCP works! (Well, it really starts at a slow rate and accelerates until packets disappear, and then the connection slows down again.) I the real world, it should work like a charm. /Fredrik
> > It is nerly FAQ. You can use Ingres qdisc to do it and attach > > policers here. > > Ah ok, I found the SYN flood example in the HOWTO. :) > But that seems to work by dropping packets rather than queueing them, > which is not so good if your bandwidth is very limited (modem dialup).You are right. I have tried to convince other QoS people about it (jamal, Werner ..) but they don''t like the idea of incomming queuing. I agree with you but let me explain one thing. When you queue (and delay) packet believing that TCP protocol will slow down then you are in mistake. TCP will adapt to new RTT by enlarging MSS which will send you even more traffic. Then queue will overflow, packet will be dropped and TCP will backoff. So that it makes sense to do incoming queuing but for different reason. Almost all queuing disciplines NEED to know whether some flow is active. And this is tested by provision of non-empty queue. This is why you need some queue. Typicaly you will want shallow queue (5 packets f.e.) and definitely you WANT to drop packets (because this is way how TCP knows about congestion). Another trick is to delay packet and MANGLE MSS value in packets. But it is far from clean approach.> > It would be nice to be able to attach every qdisc to incoming interface > > but it is not possible. There is always problem - when packet already > > hitted your box why do you want to drop/delay it ? > > Because some of the traffic is for this box (doesn''t go out) and I > don''t want it to ``steal'' all the bandwidth from traffic that is > forwarded through the box. Also, the traffic is mostly asymmetric, > lots of data coming in and only ACKs going out.You said "all the bandwidth". What does limit the bw ? Probably link between your box and ISP (e.g. modem), right ? Then the right way is to attach queues to ISP''s outgoing interface. But you probably can''t because you don''t own the ISP machines. So that you have to use "hack" and queue at incoming interface. Where the paragraph I''ve written above holds.> > On your virtual-host note. I already did patch (called IMQ) which > > implements virtual inteface allowing to attach single qdisc to multiple > > outgoing devices. > > Could you post the URL for that?Look at luxik.cdi.cz/~devik/qos/ . You could hack netif_rx routine to queue at imq-like device too and then attach qdisc to it. Or use existing ingres qdisc and change it a bit to allow queuing.> > - only there is no time to do it. > > Hmm, lack of time is a universal problem me thinks... ;)yes it is ;) Send me $300 and I''ll do it ;-))) devik
Am I correct in assuming that you only need to use the Ingres qdisc if you''re not the router between two networks (namely the internet and your customers). We have CBQ/TBF setup for our incoming traffic (internet to customer). Can the same rules be applied in reverse for outgoing traffic (customer to internet)? Thanks, Kristian Hoffmann PC-InTOUCH/FireToWire System Administrator khoff@pc-intouch.com --- On Sun, 18 Nov 2001, Martin Devera wrote:> It is nerly FAQ. You can use Ingres qdisc to do it and attach > policers here. > It would be nice to be able to attach every qdisc to incoming interface > but it is not possible. There is always problem - when packet already > hitted your box why do you want to drop/delay it ? > You should to do it on outgoing side of link to your box .. > > When you are router (not app box) then you can shape both directions. > On your virtual-host note. I already did patch (called IMQ) which > implements virtual inteface allowing to attach single qdisc to multiple > outgoing devices. > It should be relatively easy to extend it to catch incoming packets > too - only there is no time to do it. > > best regards, devik > > On 19 Nov 2001, Manfred Bartz wrote: > > > > > I would like to differentiate incoming traffic streams to guarantee > > minimum bandwidth to some services. However, as per the > > Adv-Routing-HOWTO it appears that only outgoing traffic can be shaped. > > Is this correct or is there a way of shaping incoming traffic? > > > > The problem could possibly be overcome if there is a way of routing > > traffic through a virtual host. Any tips on how to go about that? > > > > -- > > Manfred > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > > > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ >
Exactly. Ingres is needed when packet end its trip inside Linux box (so there is no queue to place it to). devik On Mon, 19 Nov 2001, Kristian Hoffmann wrote:> Am I correct in assuming that you only need to use the Ingres qdisc if > you''re not the router between two networks (namely the internet and your > customers). We have CBQ/TBF setup for our incoming traffic (internet to > customer). Can the same rules be applied in reverse for outgoing traffic > (customer to internet)? > > Thanks, > > Kristian Hoffmann > PC-InTOUCH/FireToWire System Administrator > khoff@pc-intouch.com > --- > > On Sun, 18 Nov 2001, Martin Devera wrote: > > > It is nerly FAQ. You can use Ingres qdisc to do it and attach > > policers here. > > It would be nice to be able to attach every qdisc to incoming interface > > but it is not possible. There is always problem - when packet already > > hitted your box why do you want to drop/delay it ? > > You should to do it on outgoing side of link to your box .. > > > > When you are router (not app box) then you can shape both directions. > > On your virtual-host note. I already did patch (called IMQ) which > > implements virtual inteface allowing to attach single qdisc to multiple > > outgoing devices. > > It should be relatively easy to extend it to catch incoming packets > > too - only there is no time to do it. > > > > best regards, devik > > > > On 19 Nov 2001, Manfred Bartz wrote: > > > > > > > > I would like to differentiate incoming traffic streams to guarantee > > > minimum bandwidth to some services. However, as per the > > > Adv-Routing-HOWTO it appears that only outgoing traffic can be shaped. > > > Is this correct or is there a way of shaping incoming traffic? > > > > > > The problem could possibly be overcome if there is a way of routing > > > traffic through a virtual host. Any tips on how to go about that? > > > > > > -- > > > Manfred > > > > > > > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > > > > > > > > > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/ > >