On Sat, Jun 23, 2001 at 08:30:59PM -0400, Brad Spencer wrote:
   > One potential reason for this is an overloaded ppp link.  This plagued me
   > when a 28.8 async. ppp link was my only connection to the Net.
   > 
   > What I think occurs is that there is so much backed up traffic waiting to
   > go out the pipe that the system runs out of space.  This effects UDP and
   > ICMP traffic the most.

   Which is totally unacceptable. 

   It seems unreasonable for the link to become so backed up that nothing
   can ever be sent out of it again (until it is bounced). 

At least for me, it was a classic "the bus is full" sort of problem.  Any
modern to semi-modern computer will be much faster then a 28.8 async. link
and my 300MHZ K6-2 could, with almost no effort, fill all of the buffers
up while a packet was being transmitted down the 28.8 link.

This machine does web service and other things, and when I had a 28.8
async. ppp link the router for the site, and when it started to melt, the
routing function suffered.

   Why can't it drop data with 'no buffer space' errors while it tries to
   send what it does currently have in buffers?

That is, more of less, what "no buffer space" means.  The problem is that
ICMP and UDP generally won't recover those packets.  The original post was
about name service which tends to lose because of its UDP nature.

   -- 
   "A method for inducing cats to exercise consists of directing a beam of
   invisible light produced by a hand-held laser apparatus onto the floor ...
   in the vicinity of the cat, then moving the laser ... in an irregular way
   fascinating to cats,..." -- US patent 5443036, "Method of exercising a cat"






Brad Spencer - brad@anduin.eldar.org
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]
[finger brad@anduin.eldar.org for PGP public key]