Reading Review 11-22-2004

From: Craig M Prince (cmprince@cs.washington.edu)
Date: Mon Nov 22 2004 - 04:40:55 PST

  • Next message: T Scott Saponas: "Review of MACAW"

    Reading Review 11-22-2004
    -------------------------
    Craig Prince

    The paper titled "MACAW: A Media Access Protocol for Wireless LAN's"
    described a new approach for dealing with collision detection/avoidance on
    wireless systems via media access control. Existing schemes for wired
    networks use the fact that a potential transmitter can listen on the line
    for other traffic and know if there is interference. This is the Carrier
    Sense Multiple Access (CSMA) approach; however, for wireless this is not
    an option because 1) transmission distance is finite/variable and 2) your
    own transmission is so strong that you can't detect any interference while
    you are transmitting. As a result, the authors developed a new protocol
    for getting access to the wireless "airwaves" that is a reservation type
    system.

    The authors built their protocol upon a previously proposed MACA protocol,
    which was based on four observations about the wireless environment.
    First, that "contention is at the receiver not the sender", so CSMA won't
    work. Second, that interference depends highly on location in the network.
    Third, that everyone must learn about congestion to be able to provide a
    fair allocation. Fourth, that you need to synchronize everyone to be able
    to make a good use of the media. From these observations, the key insight
    is that you create a scheme where you ask specifically before
    transmitting: RTS-CTS.

    The authors claim that the MACA protocol is flawed in that it isn't fair
    to all clients and they propose a number of changes to make it better. The
    first change is in how the nodes backoff after a collision. Instead of
    exponential backoff, they employ a multiplicative increase linear decrease
    backoff. Also, they add a mechanism to synchronize everyone's backoff
    after a transmission. This results in a fair chance for everyone to
    transmit. Another improvement is that they add an ACK message directly to
    this link layer protocol to avoid retransmissions at the TCP level.
    Finally to handle two cases where a node can still dominate they add a DS
    and RRTS messages which prevent a single client for using all the
    bandwidth.

    I liked how this paper addressed the issue of access to wireless media
    from the ground-up. Instead of relying on assumption in wired networks,
    this paper directly addresses why the existing access protocols don't work
    and systematically develops a protocol that will (hopefully) work. Another
    thing I liked about this paper is that they clearly state the cases where
    they know that their protocol will still fail. By listing the protocol's
    limitations they give the reader a better understanding of the protocol.

    I had several problem with this paper. I thought that the simulations
    conducted were very superficial and seemed to be designed specifically to
    target cases where they knew one would fail and the other would succeed.
    While this showed that their protocol has some good properties, it did not
    convince me that their protocol is necessarily the best one to use. Also,
    how their protocol performs in simulation and in practice seem like two
    very different things. I was skeptical that their simulations were not
    completely realistic. Finally, their Xerox PARC network was different then
    most wireless network and I'm not sure whether their proposed protocol
    would still be effective in a more traditional wireless environment where
    their a lot more interferrence.

    Overall, I think we can view this paper as an example of one way to design
    new protocol. By carefully analyzing the flaws of existing protocols and
    determining why those flaws occur, we can target and fix these
    specifically in our protocols.


  • Next message: T Scott Saponas: "Review of MACAW"

    This archive was generated by hypermail 2.1.6 : Mon Nov 22 2004 - 04:40:55 PST