Subject: Re: Melting down your network [Subject changed]
To: None <tech-kern@NetBSD.org>
From: J Chapman Flack <flack@cs.purdue.edu>
List: tech-kern
Date: 03/29/2005 10:23:38
Alan Barrett enumerated options:
> a) drop the packet and return 0
> b) drop the packet and return ENOBUFS
> c) delay the packet until it can be sent, then return 0
uhrm, if Jonathan's position is that only *actually dropping packets* can
achieve desired congestion control properties, and an *actually dropped
packet* is one that you had every reason to believe you successfully sent,
should there be an option
d) drop the packet and return success, that is, the packet length ?
In all the other cases, I'm not convinced we're talking about *dropping*
packets, so much as something more like, umm, *declining* packets, and (as
I think Christos may have been getting at) it's at least not transparently
clear to me that the congestion control effects of dropping and declining are
identical.
Yes, option d would be lying - though no more so than the successful return
you get before your packet is dropped at the next hop. It may be unpalatable
and I am not advocating it, just wondering if the enumeration--or the
discussion--is complete without it.
-Chap