[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ques on Diffserv on egress side only [Jamal pls read]





Sorry, seems i missed this.

On Sun, 24 Sep 2000 devik@cdi.cz wrote:

> >  Why is diffserv implemented only in the egress side  of the Linux
> > networking code?
> 
> It is because it is generaly nonsence to have ingres
> queuing in ideal world. You need only ingres limiting
> to prevent several case of DoS attacks but new (2.4)
> kernel has support for it in it's netfilter.

You mean apart from ingress qdisc?

> To Jamal: I still think that there are situation where
> ingres queuing would be useful. What about example above
> where Box1 is at your ISP and you can't alter it, Box2
> is your router which has this setup:
>                                    ---->--link1
> [Box1]-->--link-->--[Queues][Box2]-+--->--link2
>                                    ---->--link3
> 
> If you want to share link1's unused BW and use it for
> link2 and 3 you need either egress CBQ+SFQ at Box1 or
> ingres CBQ+SFQ at Box2. Or have you better idea ?
> 

So does it make a difference if you do:

                                    ---->--link1
[Box1]-->--link-->--[Box2][Queues] -+--->--link2
                                    ---->--link3


?
I am almost (99%) sure it doesnt. I'll give you the 1%.

Most routers which preach ingress queues (there are very few in this
world, as i stated earlier) do it in the hardware not in a second level
queue. (In Linux packets move from H/ware NIC FIFO
-> DMA -> backlog_queue -> Devik's_ingress_queue_here -> egress_queue).

As you can see above, delaying them at the Devik's_ingress_queue_here or
egress_queue would not make a difference. This is a shared bus media and
you are adding more clutter. I know it's cool but there is no need for
Devik's_ingress_queue_here. tag the packets using ingress qdisc and treat
them accordingly at egress.

cheers,
jamal