RE: "real" ingres implementation

["Jonathan Earle" <jearle@nortelnetworks.com>]

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?

Cheers!
Jon

> -----Original Message-----
> From: Werner Almesberger [mailto:Werner.Almesberger@epfl.ch]
> Sent: Saturday, November 04, 2000 4:59 PM
> To: Rui Prior
> Cc: linux-diffserv@lrc.di.epfl.ch
> 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
> problems.
> 
> 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 /
> /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610__________
> ___________/
>