--twz1s1Hj1O0rHoT0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 28, 2005 at 07:44:50PM -0500, Christos Zoulas wrote:
> On Mar 28,  4:30pm, jonathan@dsg.stanford.edu (Jonathan Stone) wrote:
> -- Subject: Re: Melting down your network [Subject changed]
>=20
> | > The point is much simpler:
> | >How send(2) should behave when the interface queue gets full.=20
> |=20
> | 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.
>=20
> But it does not curb congestion. I can keep spinning and sending.

I think actually it does. Yes, you can keep spinning, but you will only be=
=20
sending if there is space in the interface queue to send. So you won't be=
=20
overloading the network, you will just be spinning your CPU. That's a=20
local DOS, not a network spam. :-)

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

Agreed.

> | >Let's concentrate on that please instead of hijacking the discussion.
> |=20
> | No. Sorry Christos, but congestion control -- packet drop under
> | control -- *is* the point of the discussion.
>=20
> 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).

I'm confused. Aren't we talking about one way of the kernel avoiding a=20
flood vs another? One way is to just drop; the packet isn't sent, so no=20
flooding. The other way is to wait, so the packet isn't sent until there's=
=20
room on the net, so no flooding. ??? So either way the kernel is stopping=
=20
the app from flooding the net - one way just tries harder to avoid a UDP=20
packet drop. ??

Take care,

Bill

--twz1s1Hj1O0rHoT0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCSLmVWz+3JHUci9cRAlbdAJ0bz+hotnD2MZq5hCnmk2y0AqmqqgCeL+cN
beCBtrI5S5HnIfozM6NeARQ=
=0agE
-----END PGP SIGNATURE-----

--twz1s1Hj1O0rHoT0--