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

[hadi@cyberus.ca: Re: "real" ingres implementation]

[ Forwarding this posting to the list, because it was originally sent
  there too, but probably didn't get distributed. - Werner ]

----- Forwarded message from jamal <hadi@cyberus.ca> -----

Return-Path: <hadi@cyberus.ca>
Received: from lrcsun15.epfl.ch (root@lrcsun15.epfl.ch [])
	by almesberger.net (8.9.3/8.9.3) with ESMTP id VAA14689
	for <ica@almesberger.net>; Sat, 4 Nov 2000 21:30:45 +0100
Received: from icasun1.epfl.ch (root@icasun1.epfl.ch [])
	by lrcsun15.epfl.ch (8.8.X/EPFL-8.1a) with ESMTP id VAA02737
	for <almesber@lrcsun15.epfl.ch>; Sat, 4 Nov 2000 21:30:47 +0100 (MET)
Received: from mail1.epfl.ch (mail1.epfl.ch [])
	by icasun1.epfl.ch (8.8.X/EPFL-8.1d for ICA) with SMTP id VAA08630
	for <almesber@icasun1.epfl.ch>; Sat, 4 Nov 2000 21:30:42 +0100 (MET)
Received: (qmail 30792 invoked by alias); 4 Nov 2000 20:30:42 -0000
Delivered-To: Werner.Almesberger@epfl.ch
Received: (qmail 30788 invoked from network); 4 Nov 2000 20:30:42 -0000
Received: from mail.cyberus.ca (HELO cyberus.ca) (
  by mail1.epfl.ch with SMTP; 4 Nov 2000 20:30:42 -0000
Received: from shell.cyberus.ca (shell [])
	by cyberus.ca (8.9.3/8.9.3/Cyberus Online Inc.) with ESMTP id PAA08842;
	Sat, 4 Nov 2000 15:30:04 -0500 (EST)
Received: from localhost (hadi@localhost)
	by shell.cyberus.ca (8.9.1b+Sun/8.9.3) with ESMTP id PAA01165;
	Sat, 4 Nov 2000 15:30:12 -0500 (EST)
Date: Sat, 4 Nov 2000 15:30:12 -0500 (EST)
From: jamal <hadi@cyberus.ca>
To: Rui Prior <rprior@inescporto.pt>
cc: Werner Almesberger <Werner.Almesberger@epfl.ch>,
        "Matthew G. Marsh" <mgm@paktronix.com>, devik@cdi.cz,
Subject: Re: "real" ingres implementation
In-Reply-To: <00110418550001.00913@rd-sham.fe.up.pt>
Message-ID: <Pine.GSO.4.20.0011041512470.1072-100000@shell.cyberus.ca>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 4 Nov 2000, Rui Prior wrote:

> As I have said earlier, there are two points in favour of the implementation
> of support for regular qdiscs on ingress:
> 1. Elegancy. A qdisc should be a qdisc, no matter if the user wants it on
> ingress or egress. And this would, of course, avoid confusing the users. It's
> very confusing that you can install any qdisc on ingress and yet it won't work.
> Anyone can rightfully think: is this a bug or a "feature"?

I think elegancy also involves ability to be able to draw a line.

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

This is a bad selling point ;-> Maybe i am getting too influenced by
corporate culture or the engineering mentality: You dont do something just
because it is "cool". You do it to solve an engineering problem or maybe
(in the corporate world) because there is a market niche for it.
Necessity should be the driver.
And up to this point, nobody has provided a value statement.

> If there's already a volunteer to do the work, then what do we have to lose?

Implementing, for someone who knows what they are doing (such as devik) is
a non-issue. The big question, is why? 

What kind of services do you see using this? The web server one is weak as
Werner points out, TCP will retransmit whether you drop or delay. 
In the case of the delay, you will probably affect its RTT measurement.
I am sure if someone can provide a good answer, the objection will
disappear. So far nobody has proviuded a convincing answer.


PS:- Werner, maybe we can add an action "mark" to the policer? This will
be a work-conserving scheme (as opposed to dsmark) which will tag ECN for
example or maybe re-write the DSCP? Thoughts?

----- End forwarded message -----

 / Werner Almesberger, ICA, EPFL, CH           Werner.Almesberger@epfl.ch /