[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: "real" ingres implementation
Noone has really come out with a good reason (in layman's terms please) why
ingress qdiscs should not be. When I first looked at this traffic control
stuff, I wondered why all the work was done at the egress. After all, I
don't necessarily want (or even have the ability )to control what someone
else's box emits, but I do want to control what mine sees. I might decide to
provide extra priority to web traffic from Joe's subnet and not the larger
network. I might decide to put a cap on all FTP traffic. I might give
Sally's computer a boost in priority to more freely access my resources and
deny Stan completely until lunchtime or after hours. Perhaps I just want to
limit all inbound traffic to give myself more use of my own bandwidth. All
this would be done on the ingress, so why the poopoo-ing of ingress qdiscs?
> -----Original Message-----
> From: Werner Almesberger [mailto:Werner.Almesberger@epfl.ch]
> Sent: Saturday, November 04, 2000 4:59 PM
> To: Rui Prior
> Cc: email@example.com
> Subject: Re: "real" ingres implementation
> Rui Prior wrote:
> > 1. Elegancy. A qdisc should be a qdisc, no matter if the
> user wants it on
> > ingress or egress.
> Hmm, I remember fighting the concept of having any ingress qdisc ;-)
> Agreed, it's not nice to have a qdisc that's just a crutch because
> we don't have any better way to attach the classification mechanisms.
> This is something we should fix in 2.5 (by eliminating the qdisc).
> > 2. If you provide the tools, someone will find a way to
> make good use
> > out of them. Possibly in some unusual and ingenious way no
> one had thought
> > before.
> And a lot more people will find ugly pseudo-solutions involving the
> ingress qdisc, and we may never find the "right" solution for those
> Assuming the two extensions I've described in my previous posting are
> in place (with the slight extension that the EDF qdisc can configured
> to shape, i.e. to wait until the deadline is actually reached), could
> you think of any realistic example that would still require ingress
> queuing in this case ?
> > If there's already a volunteer to do the work, then what do
> we have to lose?
> Once we put in a fully featured ingress qdisc, it will be hard to get
> rid of it. I think most people don't like rewriting their tc scripts
> every few months (particularly if it took them several weeks to get
> them to work in the first place ;-)
> - Werner
> / Werner Almesberger, ICA, EPFL, CH
> Werner.Almesberger@epfl.ch /