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

On Tue, Mar 29, 2005 at 11:57:32AM -0500, J Chapman Flack wrote:
> Bill Studenmund quoted me
> > > I think Christos may have been getting at) it's at least not transpar=
ently
> > > clear to me that the congestion control effects of dropping and decli=
ning are
> > > identical.
>=20
> and responded
> > I think the point Jonathan was trying to make on this is that it doesn'=
t=20
> > matter.
>=20
> I think you are right that Jonathan was making that assumption.  The
> assumption may even be right, but, as it was precisely my aim to point ou=
t,
> it is not transparently self-evident.  An argument showing that it really
> doesn't matter would convert making-an-assumption into making-a-point.

I think Jonathan gave it when he refered to the end-to-end papers. I=20
haven't read them, but from pondering his comments in reference to them, I=
=20
think they make-the-point for this.

> > 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.
>=20
> I understand the sense in which you are using the word 'drop'.  I'm remin=
ding
> you that there is another sense of the word 'drop', in which the send *di=
d*
> happen, in all respects that the sender can see, but the receiver did not
> get the packet, and this is a sense commonly used in reasoning about best-
> effort delivery systems.  If you stand far enough away, you can say both
> senses are the same in that a completed message exchange didn't happen, b=
ut
> that's only when you stand too far away to see the error recovery and
> queueing properties of the protocols involved, and I'm not convinced those
> are irrelevant to this thread.

I think part of the discussion involves the error recovery properties of=20
UDP, which is "oh well." :-)

Also, I think an important part of what Jonathan was saying is the=20
following logical chain:

1) If you have a protocol on a network (or the open internet in an=20
extreme), you have to deal with resource limits and packet drops. Packets=
=20
will drop and we don't have our own point-to-point gigabit connections to=
=20
everything.

2) To cope with packet drop and resource limits, you need some sort of=20
congestion control and rate limiting. This means complexity in your=20
protocol code. For something based on UDP, this code would be the code=20
that calls sendmsg() or sendto().

One part of the above is, as best I can tell, that you want something like=
=20
AIMD (Additive increase multiplicative decrease) rate limiting. I admit=20
this is now an active area of research and I'm not up on the literature.=20
The main point for this discussion though is that if you start to be=20
congested, you need to do something like MD to back off your transmission=
=20
in order to keep the network stable.

3) Once you have that complexity, the difference between "dropped" and=20
"declined" packets isn't that great. If it doesn't go, you need to do=20
something to reduce your rate to keep the network stable.

I mean, what if the main congestion source is the fact someone started a=20
second copy of this program on your box? :-) Neither thread will EVER get=
=20
full line rate, but the two of them together can keep the interface queue=
=20
full...

Thus you want to trigger some sort of congestion avoidance if you fill up=
=20
the local queue. Perhaps you may want less than halving your transmission=
=20
rate, but you should do something...

Take care,

Bill

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

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

iD8DBQFCSZ5PWz+3JHUci9cRAsV/AKCRBtkisixJRW9KGb47J/vc0FEUPACeJHMM
Ucg3y3kHbBfOP03WbknwUM4=
=JaCt
-----END PGP SIGNATURE-----

--yEPQxsgoJgBvi8ip--