Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!CLS.LCS.MIT.EDU!james
From: james@CLS.LCS.MIT.EDU (James W. O'Toole Jr.)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Avalanche
Message-ID: <8605310436.AA25051@CLS.LCS.MIT.EDU>
Date: Sat, 31-May-86 00:36:00 EDT
Article-I.D.: CLS.8605310436.AA25051
Posted: Sat May 31 00:36:00 1986
Date-Received: Sat, 31-May-86 15:57:36 EDT
References: <8605300339.AA08753@COMET.LCS.MIT.Edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 18
Approved: tcp-ip@sri-nic.arpa


	From: dcf@comet.lcs.mit.edu (David C. Feldmeier)
	Subject: Avalanche

	I suspect that on an Ethernet, this would be a bigger mess
	because of the multiple collisions.

I wouldn't expect multiple collisions, just one: then the ``randomness''
in the backoff times ought to break the symmetry.  This is an interesting
way to get collisions though.  Usually the biggest cause of Ethernet
collisions is the transmission of a long packet.  If two other hosts
become ready to transmit during that time, they will both begin
transmitting shortly after the long packet's end.

Curious, the gateway's broadcast acts as a synchronizing event, so that
the independent transmission times assumption fails.

  --Jim