> There one and is only one acceptable answer: such a scenario is
> congestion, and under such congestion we _must_ drop packets.

No.  That is one of the possible responses; there are others (though
the only one that comes to mind is to throttle the sending code back by
delaying send attempts).

> To guarantee stability, I believe a stronger push-back is required
> than can be given by merely sleeping until the interface queue has
> space: the classic multiplicative decrease part of AIMD.

> If you want to disagree, please first re-read Van Jacobsn's paper on
> congestion control, including the cited Royal Society paper with the
> underlying justification.

You appear to be making a classic mistake: assuming that everyone else
is using the network for the same purpose, or in the same way, that you
are.  Van Jacobson's work is very valuable, and it's doubtless very
valid given its assumptions - but those assumptions probably include
things like assuming it's a shared multipurpose network, or that it's
used principally for connection-oriented data streams and applying
backpressure to all congesting streams is an appropriate response to
congestion.

Since in this case the entire infrastructure is Emmanuel's, and the
application is one for which those do not apply, Van Jacobson's work
quite likely also does not apply.

> The key point here is that any well-behaved OS _should_ stop Emmanuel
> from creating the sustained congestion he is deliberately setting out
> to create.

"Unix does not stop you from doing stupid things because that also
stops you from doing clever things."  What Emmanuel is doing here would
be stupid if done over shared long-haul networks, but it is a perfectly
reasonable thing to do over a dedicated private LAN - and I thus
believe NetBSD should not make it impossible, nor especially difficult.
We ship with so many other effective foot-shooting devices, from
"ping -f 204.152.190.13" to "su -c 'rm -rf /'", I see no reason to get
bent out of shape over this one.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B