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

On Tue, Mar 29, 2005 at 10:23:38AM -0500, J Chapman Flack wrote:
> 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
>=20
> 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
>=20
>     d) drop the packet and return success, that is, the packet length  ?

As mentioned earlier, that's what everyone took (a) to mean.

> 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.

I think the point Jonathan was trying to make on this is that it doesn't=20
matter. The application called send() and the packet didn't go. To quote=20
the man page, "send(), sendto(), and sendmsg() are used to transmit a=20
message to another socket." That didn't happen. Thus it was a drop.

Take care,

Bill

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

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

iD8DBQFCSYRBWz+3JHUci9cRApHeAJ9ABKblJNw1i6d6zgnZj9IoszD9EACggG4D
i2egSNFT3yqW5dInS6IfyBk=
=nXNi
-----END PGP SIGNATURE-----

--dDRMvlgZJXvWKvBx--