Re: ping: sendto: No buffer space available

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Oct 10, 2011 at 10:05:14AM -0700, Erik E. Fair wrote:
> I'd like to clarify my thinking here. We're talking both about
> networking, in which we commonly lose data (sometimes by design,e.g.
> in network congestion situations at IP routers), and we'retalking
> about UNIX kernel system call API.
> 
> In my opinion, when the kernel is interacting with a userland
> application, it should *never* silently drop (lose) data.

I strongly disagree with your opinion.  The userland application
requests a particular class of service from the kernel when it
creates a socket.  SOCK_DGRAM explicitly requests unreliable transport;
if you want reliable transport, you need to request SOCK_SEQPACKET.

The userland application *is already buggy* if it requests SOCK_DGRAM
service and yet cannot cope with packets silently being dropped (lost)
at any arbitrary point in the network.  From its point of view, what
difference whether they overflow a buffer in the local kernel, an
intermediate router, or the receiving end-node?  It must implement
correct behavior in the presence of unannounced packet loss, or it has
a bug.

Given that most packet loss on most networks is caused by or at least
related to data rate, it is in fact the case that it must also, for
correct operation, implement some means of flooding avoidance.  In the
absence of positive notification that flooding is occurring, since it
is usually the case that there will be no such notification.

What you are arguing for would seem to be that applications which have
explicitly requested unreliable packet delivery should nonetheless be
coded with two separate paths for handling lost packets: one for a
case in which you are advocating that the local kernel provide
notification that the packet was lost, and one (which _must_ be present
anyway) for packets lost elsewhere in the network, which the local kernel
by definition cannot notify about.

So.  More application complexity, still the requirement to cope properly
with silently dropped packets, finally -- and worst of all -- possibly
a change in the semantics of datagram sending such that _the overwhelming
majority of existing event-driven applications that actually send datagrams
will misbehave_.  This is because new blocking behavior will be introduced
at an operation that previously (and correctly) would silently drop the
sent message.

Not a good thing.