Some measurements and some questions

[Brecht Vermeulen]

Hi Eddie,

thanks for the answers, I was on holidays till now, so I couldn't read it
earlier.


On Tue, 22 Aug 2000, Eddie Kohler wrote:

> Hi Brecht, sorry for so long getting back to you.
> 
> > * it seems that the routing table is a very consuming component, see the
> > document between click 3 (entries for 2 subnets) and click 4 (entries for
> > 5 subnets) which makes the latency a lot higher than the standard linux.
> > Is this a known issue ?
> 
> This is a known issue. Unfortunately, much of the published routing table
> work has been patented, and we cannot include it. We are not real routing
> table hackers so we just left it at that. Do you know of any good
> unpatented routing tables? Or, of course, you could write a better one and
> contribute it to the Click distribution :)

I didn't know the Linux one was patented and I do not know of other ones
and I'm certainly not able to write one myself.
My intention is to write CORBA interfaces on top of the click router and
use the Click router as a Diffserv router (edge and core) which has to be
configured via a management architecture, which is the subject of my
research, and not directly the router an sich. Therefore I did the
measurements to know if the click router was very much slower than the
linux router (the architecture of the Click router is a lot clearer than
the standard linux QoS part, so it's easier to write a CORBA interface on
top of the click router), and it turned out to be faster, so the decision
is made fast to write CORBA interfaces on top of Click instead of Linux.

> > * If there is given a parameter which is bigger than 2100000 bytes per
> > second (16Mbit/s), the /proc/click/meter/meters gives a minus rate and the
> > component doesn't do what is expected.
> 
> We will fix this to give a warning.

so it is not possible to meter flows bigger than 2100000 bytes per sec ?
Is there any particular reason for this or can it be changed ?

> 
> > * Is there an upcoming meter component which has the behaviour as needed
> > in diffserv, this is all traffic under the limit goes through and only the
> > out of rate packets are dropped or remarked. Now the meter component sends
> > all traffic to one output according to the rate. (e.g. a 2 Mbit stream
> > through a 1 Mbit meter goes all trhough output 1, but normally only
> > half of the traffic should be going through output 1)
> 
> There will be one soon. The problem is preventing burstiness; not clear
> what the best way is. Maybe not in Click 1.1. Do you have any ideas here?

Maybe out of
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-04.txt :

5.2.1.  Average Rate Meter
5.2.2.  Exponential Weighted Moving Average (EWMA) Meter
5.2.3.  Two-Parameter Token Bucket Meter
5.2.4.  Multi-Stage Token Bucket Meter

See over there for more details.


> Not right now, but that is probably the best reason we've heard to actually
> bother to do it. Are you interested in helping?
I've not the time, I'm afraid of.

> 
> > * Is it possible to print the tulip stats as in the function
> > tulip_print_stats ?
> Could you explain what you mean? When do you want to print this?

Well, e.g. in the proc interface, to get information about the polling and
packets e.g.


best regards,
Brecht