Re: network queue lengths

[Michael Richardson <mcr%sandelman.ottawa.on.ca@localhost>]

>>>>> "Thor" == Thor Lancelot Simon <tls%rek.tjls.com@localhost> writes:
    >> This is getting a bit long, so I am going to hastily draw some
    >> conclusions.  Please tell me if I am way off base:

    Thor> Let me say up front that I don't much care about ALTQ, and I
    Thor> care more about not harming performance on machines with very
    Thor> fast networks on both sides (or their only "side") than about
    Thor> reducing latency on machines with dramatically mismatched
    Thor> networks.

  I understand your point of view.
  I think this is a question about, if there was a tunable, what would
the default be, and which group of people possess the smarts to tune it
the "other" way.
  One important thing might be to treat packets forwarded differently
from those locally generated.  This inheritely distinguishes machines
with only one "side"...

    >> 2 maximum queue/ring lengths in NetBSD are tuned for very
    >> high-speed networks, now; the maximums should adapt to hold down
    >> the expected delay while absorbing momentary overflows.

    Thor> Can we trust the "baudrate" reported by an interface?  If we
    Thor> can, it should be possible to algorithmically tune this, but
    Thor> knowledge of the system's network topology and characteristic
    Thor> packet flows -- which can probably be inferred at runtime --
    Thor> may be required in order to get it right.

    Thor> Constant, parametric tuning like "grow the queue until latency
    Thor> hits _X_" seems highly likely to interact in very negative
    Thor> ways with TCP.

  As long as the measurement of the latency was done over a period of
many minutes to hours, and was not permitted to change too quickly, I
think that the effects of this would not be important compared to
congestion in the network itself.
  The periods involved would ideally be randomized such that a network
of machines with this behaviour do not get into some kind of cycle as a
group.   now... this is where the simulations become important.

-- 
]     Y'avait une poule de jammé dans l'muffler!!!!!!!!!        |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr%sandelman.ottawa.on.ca@localhost http://www.sandelman.ottawa.on.ca/ 
|device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [