Ok, I'm about half way through writing up a patch set to implement
the bandwidth delay product write-buffer calculation. It may still be a
few days before it is presentable. The TCP stack already has almost
everything required to do the calculation. Adding a fair-share piece in
addition to the bwdelay product will also be fairly easy, at least for
the write-side.
The basic problem with calculating the bandwidth delay product is that
it is an inherently unstable calculation. It has to be a continuous,
slow moving calculation or you have a good chance of destabilizing the
network (think about having a thousand connections all trying to figure
out each of their bandwidth delay productions for traffic sharing random
hops in the network). The advantage of being able to do it successfully,
however, is huge. Rather then allowing the TCP connection to start to
lose packets before backing off, the bandwidth delay product calculation
instead focuses on not overloading the network in the first place while
still maintaining optimum performance.
I took a look at the paper Leo pointed out to me:
http://www.psc.edu/networking/auto.html
It's a very interesting paper, and the graphs do in fact show the type
of instability that can occur. The code is a mess, though. I think it
is possible to generate a much less noisy patch set by taking a higher
level approach to solving the problem.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message