Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!well!nagle
From: nagle@well.UUCP (John Nagle)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: ether collision backoff
Keywords: non-standard
Message-ID: <14015@well.UUCP>
Date: 9 Oct 89 16:53:56 GMT
References: <42686@sgi.sgi.com>
Reply-To: nagle@well.UUCP (John Nagle)
Lines: 44

In article <42686@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>At last week's Interop, I was told that a large workstation company's
>products can be configured to use non-standard retransmission-after-collision
>delays.
>
>Is this true?  Does it cause big problems, as my informant implied?

      The issues here are very subtle.  Hosts that use shortened backoff
delays are engaging in economic warfare with other hosts on the cable for
a bigger share of the network bandwidth.  Attempts to do this on nets with
more than a few hosts may result in congestion collapse, at the link rather
than the datagram layer.

      Packet networks are actually computational ecologies in which the hosts
are competing for resources.  Certain types of competition result in
economic instability.  Ethernet hosts contend for resources, but under a
uniform discipline that makes the contention fair.  By violating the
rules, a host can improve its share of the resource at the expense of
other hosts.  However, in doing so, it increases the number of collisions
on tries ohther than the first.  This reduces the overall capacity of the
cable, because a higher percentage of the bandwidth is lost to collisions.
Thus, the optimial strategy for the host is suboptimal for the network.
Continued pursuit of the optimal strategy for the host results in the 
network operating in a grossly suboptimal way.  In networks, we call this
congestion collapse.  In economics, it's called the "tragedy of the
commons."

      Back in 1984, somebody at Sun turned down the retransmit delay in
4.2BSD's TCP, apparently hoping to "improve performance".  The resulting
mess caused trouble in the Internet for years.  (See my paper in IEEE
Trans. on Communications, April 1987, for details.)  

      Is it Sun again?

      General advice: DON'T DO THIS unless you can establish by both
mathematical calculation and tests on large networks that you are not
introducing instability.  Operationally, the way this class of problem
manifests itself is that everything works fine until a momentary network
overload occurs, and then throughput drops while net traffic remains 
heavy.  After a while, connections fail, network traffic drops, and
things return to normal, leaving users angry and puzzled.

					John Nagle