Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!crayamid.cray.com!ug051
From: ug051@crayamid.cray.com (Michael Nittmann)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  ether collision backoff
Message-ID: <8910100857.AA06027@crayamid.cray.com>
Date: 10 Oct 89 08:57:47 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 27

comment: ethernet retransmission upon collision is way down below IP
and on the tcp/ip level you should not bother.

the "standard" retransmission serves to scatter the retransmission events
in time space since a collision is detected always on all neighbouring
hosts on an ethernet trunc . 
It is in fact that the electrical messages spreading out on the ethernet 
trunc overlap (at least partially) and scramble. By the way the detection is
done purely on hardware level: when two signals arrive the energy on the
cable is higher and this leads to collision detect going off.

When all people use the same algorithm of retransmitting timing, which
contains a statistical element (random number dependent) that is
different for all hosts (the point is different for all hosts) you have a
pretty good guaranty that they will not (yes, NOT) retransmit at the same
time. When you start using different algorithms, there might be accidental
"resonances" between the different algorithms, causing perhaps during 
some instatnces of retransmittals two hosts to retransmit in a time interval
than might lead to new collisions.
Even if the new algorithm seems "better", in a fairly local region (about the length
of an ethernet packet or between bridges) all hosts should use about the same
algorithm to avoid accidental synchronous retransmissions.

Even in an environment where collisions are frequent, I would not change the
retransmission algorithms but scope the line to see who spoils it.

michael