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

On Mon, Mar 28, 2005 at 06:54:53PM -0800, Jonathan Stone wrote:
> In message <20050329021237.GF11361@netbsd.org>Bill Studenmund writes
>=20
> >> | 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.
> >> =3D20
> >> That is the job of a higher level protocol/api not send()
> >
> >Agreed.
>=20
> Bill,
>=20
> No, that's incorrect; I suspect you don't understand the issue
> (or don't see it the way a networking expert will see it).

Uhm Jonathan, I'm confused. I thought I was saying that I don't want=20
udp_send getting all super-fancy about packet sending/delaying. How=20
exactly are we disagreeing?

> Here is the key point again:
>=20
> An ill-behaved app can *always* attempt to overflow a queue. The queue
> under discussion here as a potential victim of overflow attaks is the
> per-interface if_snd queue.
>=20
> Thus, the question under discussion is: what should we do under
> sustained overload (or attempts to sustain overload) of the if_snd
> queue?  Specifically, when an app using UDP (or other unreliable
> datagram protocols) uses non-blocking I/O to persistently overflow the
> if_snd queue?
>=20
> The most correct anwser is: we should drop packets.

That's actually what I think we should do. So how exactly are we=20
disagreeing? I'm now really confused....

> >I'm confused. Aren't we talking about one way of the kernel avoiding a
> >flood vs another? One way is to just drop; the packet isn't sent, so no
> >flooding. The other way is to wait, so the packet isn't sent until there=
's
> >room on the net, so no flooding. ??? So either way the kernel is stopping
> >the app from flooding the net - one way just tries harder to avoid a UDP
> >packet drop. ??
>=20
> Bill, this is where I say: please go back and read that part about the
> multiplicative decrease part of AIMD.  Dropping packets is a better
> solution than simply delaying the application for just long enough for
> the queue to drain, and then let the malformed app continue its
> denial-of- service behaviour.

Jonathan, please look closer at what I wrote (or help me understand how I=
=20
could have been clearer). I was not trying to argue that we should block=20
rather than drop. I was commenting on the fact that both options are a way=
=20
that the kernel involves itself in rate-limiting transmissions. So the=20
idea that the kernel does nothing here is incorrect.

Take care,

Bill

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

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

iD8DBQFCSOqMWz+3JHUci9cRAo93AJsEbjHmohYumRtDKF6F9cgtaGxCfACeKJ62
6tRpAZkJx8tpv2EvpgHz+R4=
=+wso
-----END PGP SIGNATURE-----

--ZPt4rx8FFjLCG7dd--