On Mar 26,  6:59pm, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
-- Subject: Re: fixing send(2) semantics (kern/29750)

| 
| In message <20050326235313.E48372AC9C@beowulf.gw.com>,
| Christos Zoulas writes:
| 
| >On Mar 27, 12:28am, manu@netbsd.org (Emmanuel Dreyfus) wrote:
| 
| [[ feedback points 1 through 6]]
| 
| You missed out:
| 
| 7.  This whole suggestion is based on a fundamental misunderstanding
| of how packet networks work, and of what SUS requires.  Not only is it
| not necessary, its actively harmful in (for example) cases of
| sustained congestion.
| 
| I don't have the prose skills to explain, to this audience, the
| background behind this key conclusion in a short email.  For those who
| understand Van Jacobson congestion avoidance (i.e., have read the
| papers), one need say no more than repeat the observation that, under
| heavy network load as evidenced by full queues, one is better off to
| drop packets at their source than to try and resorces sending them
| into the network, only to have them dropped later.

This is a different scenario. The cpu is a lot faster than the nic
card, and the nic card cannot absorb packets quickly enough to send
it out to the network. It is not congestion in the network fabric,
but internal congestion. There is also currently no way to rate limit
send so that it does not return ENOBUFS from the application side,
and this is clearly broken. I.e. I cannot even select or poll before
I send, in order to avoid gettting ENOBUFS.

christos