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>