[LARTC] Shaping incoming traffic?

[LARTC] Shaping incoming traffic?

[Manfred Bartz]

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/

Re: [LARTC] Shaping incoming traffic?

[Martin Devera]

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/

Re: [LARTC] Shaping incoming traffic?

[Manfred Bartz]

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



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

Re: [LARTC] Shaping incoming traffic?

[Michael T. Babcock]

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.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

Re: [LARTC] Shaping incoming traffic?

[Fredrik Björk]

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


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

Re: [LARTC] Shaping incoming traffic?

[devik]

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


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/

Re: [LARTC] Shaping incoming traffic?

[Kristian Hoffmann]

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/

Re: [LARTC] Shaping incoming traffic?

[Martin Devera]

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/
> 
> 


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/2.4Routing/