On Mar 28,  4:30pm, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
-- Subject: Re: Melting down your network [Subject changed]

| > The point is much simpler:
| >How send(2) should behave when the interface queue gets full. 
| 
| No Christos, that point is not open for discussion.  There one and is
| only one acceptable answer: such a scenario is congestion, and under
| such congestion we _must_ drop packets.  If for nothing else, to curb
| congestion by misbehaving apps.

But it does not curb congestion. I can keep spinning and sending.

| 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.
 
That is the job of a higher level protocol/api not send()

| 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.  (I have to run to a meeting; I will send a
| full citation later this evening if you wish.)
| 
| Jon Crowcroft has alluded, on the e2e mailing list, to newer results
| in control theory, based on newer analysis in the complex plane, which
| may allow a looser response to congestion; I have never found the
| details alluded to. If you can, I'd be glad to discuss them.
| 
| 
| 
| >Let's concentrate on that please instead of hijacking the discussion.
| 
| No. Sorry Christos, but congestion control -- packet drop under
| control -- *is* the point of the discussion.

The point of the discussion is the behavior of send() on a full
interface. If an application decided to flood the network, it is
not the job of the kernel to stop it (in UDP).

christos