[Bloat] Hmmn, this is in part a capacity planning/management problem.

["Collier-Brown, David (LNG-CAN)" <David.Collier-Brown@lexisnexis.ca>]

I was reading the latest article in LWN, and commented there, but part
of the comment may be relevant to the list...

-- reply to mlankhorst (subscriber, #52260) --
Changing the subject slightly, there's a subtle, underlying problem in
that when developing products and protocols, we tend to work with what's
easy, not what's important.

We work with the bandwidth/delay product because it's what we needed in
the short run, and we probably couldn't predict we'd need something more
at the time. We work with buffer sizes because that's dead easy.

What we need instead is to work in the delay, latency and/or service
time of the various components. It's easy to deal with performance
problems that are stated in time units and are fixed by varying the
times things take. It's insanely hard to deal with performance problems
when all we know is a volume in bytes. It's a bit like measuring the
performance of large versus small cargo containers when you don't know
if they're on a truck, a train or a ship!

If you expose any time-based metrics or tuneables in your investigation,
please highlight them. Anything that looks like delay or latency would
be seriously cool.

One needs very little to analyze this class of problems. Knowing the
service time of a packet, the number of packets, and the time between
packets is sufficient to build a tiny little mathematical model of the
thing you measured. From the model you can then predict what happens
when you improve or disimprove the system. More information allows for
more predictive models, of course, and eventually to my mathie friends
becoming completely unintelligible (;-))

--dave (davecb@spamcop.net) c-b
--

As you might guess, I'm a capacity planner, and might be able to help a
bit on the modeling side. Besides, I'm looking for a networking example
for my next book (;-))

--dave