1. In defense of random access
Konstantinos Psounis
October 2007
In defense of random access
Konstantinos Psounis
EE and CS dept.
USC
University of Southern California

2. Questioning popular wisdom
Konstantinos Psounis
October 2007
Questioning popular wisdom
Popular wisdom:
random access is inefficient
random access is unfair
Reality check
consider the most popular CSMA/CA protocol,
compare to optimal (collision-free) scheduling
when performance suffers, understand what is the real source of trouble
it might have little or nothing to do with random access
University of Southern California

3. Konstantinos Psounis
October 2007
Inefficient? 1
Flow 1
Flow 2 2 3 15 14 13
Max-min fair rate allocation point
(63% of the optimal)
Saturation point
Saturation conditions (all nodes have packets to send all the time) are neither realistic nor very insightful
Use rate control (a reasonable transport protocol) to operate in a different point in the region!
University of Southern California

4. Unfair? Again the rate region offers plenty of good options
Konstantinos Psounis
October 2007
Unfair? 1 4 7 2 3 5 8 6 9
Flow 1
Flow 2
Flow 3
Max-min fair rate allocation point
(91% of the optimal)
TCP
Saturation point
Again the rate region offers plenty of good options
But, TCP operates the network at a rather bad (unfair) point
Use another rate controller!
University of Southern California

5. What type of rate-control?
Konstantinos Psounis
October 2007
What type of rate-control? f1 f4 f3 S D f5 f2
Interference-aware, neighborhood-centric
University of Southern California

6. What type of rate-control?
Konstantinos Psounis
October 2007
What type of rate-control?
Proof of concept:
when a queue gets congested, one hop neighbors of the sender and receiver mark flows going through their incoming and outgoing links and sources react
distributed, easy to implement, in-network changes only
TCP
Max-min
Saturation
Neighborhood-centric
University of Southern California

7. How bad can random access be?
Konstantinos Psounis
October 2007
How bad can random access be?
Worst-case scenario:
many edges interfere with the edge under study, but they don’t interfere with each other
In practice, such topologies (with more than 2-3 such neighbors) rarely occur
Aside: a similar setup has been used to argue about worst-case scenario for maximal versus maximum weight matching, further motivating the intuitive correspondence of random access to maximal matching
two cases depending on flow direction in the edge under study
University of Southern California

8. Other points Do not dismiss RTS/CTS
Konstantinos Psounis
October 2007
Other points
Do not dismiss RTS/CTS
Improve RTS/CTS (for multi-hop scenarios)
Trouble from auto rate adaptation:
the physical header is always sent at the lowest rate 
the transmission time of this header can be equal to that of a data packet, when the later is send at high speeds
this problem is unrelated to the scheduling scheme used, yet magnifies the overhead of RTS/CTS (or any other control plane message, e.g. ACKs) 1
Flow 1
Flow 2 2 3
Flow 1
Flow 2
RTS/CTS works
RTS/CTS doesn’t work
(when Flow 2 is on, Flow 1 collides)
University of Southern California

9. Konstantinos Psounis
October 2007
Summary
Random access can be efficient and fair as long as it is paired with the right rate controller
one can design distributed, easy to implement controllers that do the job
The worst-case performance of random access is good when real-life limitations are taken into account
e.g. there can’t be many edges that are not interfering with each other, yet they all interfere with the edge under consideration
Random access is often accused for somebody else’s sins, e.g.
wireline-inspired rate controllers that fail to regulate all contending flows
inefficiencies cause by auto rate adaptation
etc.
University of Southern California