MAC sublayer protocol

[uunet!aupair.cs.athabascau.ca!rwa]

Glenn points out that my trivial solutions [1-3] attempt to reduce the
cell size, and correctly notes that given the vagaries of nature,
guaranteeing the bounds of a cell is just about impossible.  I think
the reference to W6's qrm'ing the Hawaiian repeaters is just a touch
extreme - sure it happens, but that's got to be the absolute worst
case.  If all proposed cures must deal with ducting of that order it's
sure going to cut down on the solution space.

Alright, instead of using a fixed `budlist' [an execrable term IMHO]
approach as the repeat filter, go to a dynamic list with some sort of
maximum size as a function of offered load.  I can imagine a range of
policies for adding a new station to the list and aging current
stations off the list, based on stations heard, traffic levels, what
kind of traffic patterns you're trying to optomize for
(bursty/interactive or steady/bulk transfer).

You could even do things like selectively rejecting frames from
over-active stations in an attempt to make them back off as a form of
load throttling (the basic internet choke packet approach :-), and
strike them from the repeatable list if they were too persistant.
Since it's a full CSMA/CD environment, rejecting a packet is cheap -
the repeater doesn't need to get more than the first 20 or so octets
before it can decide to issue a REJ or fake a collision.  This is an
interesting research area, which is a way of saying I haven't got many
ideas as to the best way(s) to set policy.

If you couple this with a map-colouring approach to frequency
coordination between cells (have four repeater frequencies and reuse
them in the obvious way) it should go a long way.

The fact is that there is a tension between cell size, admin overhead,
and the facts of life (propagation and human psychology).  Which do you
want to optimize for?  As the man said :-) "cheap, fast, or reliable;
choose two".

--
Ross Alexander    rwa@cs.athabascau.ca    (403) 675 6311    ve6pdq