[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