> Date: Mon, 3 Aug 1998 16:24:02 +0200 (MET DST)
> From: "Felix A. Croes" <felix@xs1.simplex.nl>
> Message-Id: <199808031424.QAA06119@xs1.simplex.nl>
> To: sommerfeld@orchard.arlington.ma.us
> Subject: Re: kern/5901: ppp fast queue too fast
> Cc: gnats-bugs@gnats.netbsd.org
> 
> > I don't think this is the right fix, since you're doing the sharing by
> > packets transferred instead of by bytes transferred.
> 
> Yes, it should be called a workaround rather than a proper fix.
> 
> 
> > Putting LCP packets into the fast queue would seem to be more like the
> > "right" answer.  (I'm not sure about `ping's though..)
> 
> I disagree.  What you're saying is basically that all essential packets
> should be in the fast queue, and then it would be okay if the other
> packets cannot get through.  However, the system cannot possibly
> determine which packet is essential and which isn't.  What about
> keepalive packets?  Surely it must be possible to have low-priority
> keepalive packets.  And should all my normal-priority connections
> freeze for an hour if I download a big file from download.gamespot.com?

Yeah, but we're now starting to creep into the realm of weighted fair
queueing and similar complexity.

At some level, this belongs in protocol independant code..

in some web browsing doing some research on RED and the like, I found
a pointer to the following:

   http://www.csl.sony.co.jp/person/kjc/programs.html

.. which appears to be an implementation of a number of .. more subtle
.. queue management algorithms for FreeBSD.  should be fairly
straightforward to port into NetBSD..

						- Bill