Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Feb 2002 09:49:37 -0800
From:      "Kevin Oberman" <oberman@es.net>
To:        Michael Sierchio <kudzu@tenebras.com>
Cc:        Vinod Namboodiri <geekvinod@yahoo.com>, Jason Hunt <leth@primus.ca>, freebsd-net@freebsd.org, freebsd-mobile@freebsd.org
Subject:   Re: MAC Layer of TCP/IP stack 
Message-ID:  <20020215174937.7A12F5D0C@ptavv.es.net>
In-Reply-To: Your message of "Fri, 15 Feb 2002 09:29:54 PST." <3C6D4592.8010809@tenebras.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 15 Feb 2002 09:29:54 -0800
> From: Michael Sierchio <kudzu@tenebras.com>
> 
> Kevin Oberman wrote:
> 
> 
> > In wireless (802.11) protocols there is also no CSMA/CD as it is not
> > applicable to wireless although there IS a MAC and it is usually
> > loadable, though documentation and source is proprietary and general
> > hard to get.
> 
> 
> 802.11 supports CSMA/CA, where the A stands for the
> avoidance algorithm -- CD is impossible where the transmit and
> receive antennas are coincident.
> 
> And I don't know why you declare CSMA/CD rules to be "broken" -- they've
> 
> worked surprisingly well since Metcalfe and Boggs devised Ethernet.
> 
> The major problem as I see it is that the wait period is defined by
> the physical layer constraints (fixed time),  whereas increasing
> bandwidth makes the wait time a higher and higher percentage of
> the bandwidth.
> 
> There are certainly wireless cards that permit 802.11 raw frame
> processing by the host -- this is a great help to those miscreants
> who engage in the exercise of driving around and snooping on
> others' 802.11 nets with the excuse that they're "helping" the
> rest of us.

This is getting a bit off-topic, but the problem with the CSMA/CD
algorithm is that it allows a single system to "sync" with the
collision back-off and monopolize the link to the exclusion of other
systems. This is not intentional hogging but a simple artifact of the
mechanism interacting with a system sufficiently fast to always have
the next frame ready to transmit immediately after the IFG. Because of
the common use of switches which break up the collision domain, this
is very seldom a problem and is never more than a minor annoyance
unless something else is broken. This is well documented in some IEEE
papers from back in the late 80s.

The problem is in the collision back-off algorithm. A replacement
called BLAM was proposed. It is fully interoperable with the 802.3
mechanism but would place system running it at a disadvantage in
gaining access to a busy network. As a result, no vendor wanted to
implement it. I don't think the 802.3 committee ever even considered
adding it to the spec.

I think Jeff Mogel at Digital did the work on this, but it is many
years old and I no longer work with Ethernet at this level (and hardly
at all except to plug in my computer) and I don't have a ready
reference for all of the older stuff. (I do still have my trusty, if
outdated copy of 802.3, though.)

While many cards (both 802.3 and 802.11) allow the user to generate
raw frames, this is not really a MAC adjustment. Things like collision
handling, FCS and error generation are beyond what is normally
available to the user.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@es.net			Phone: +1 510 486-8634

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020215174937.7A12F5D0C>