In defense of random access

1
In defense of random access
Konstantinos Psounis EE and CS dept. USC
2
Questioning popular wisdom

• Popular wisdom
• random access is inefficient
• random access is unfair
• Reality check
• consider the most popular CSMA/CA protocol,
  802.11
• 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

3
Inefficient?

• 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!

4
Unfair?

• Again the rate region offers plenty of good
  options
• But, TCP operates the network at a rather bad
  (unfair) point
• Use another rate controller!

5
What type of rate-control?
f1
f4
f3
S
D
f5
f2

• Interference-aware, neighborhood-centric

6
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

7
How bad can random access be?

• Worst-case scenario
• many edges interfere with the edge under study,
  but they dont 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

8
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)

9
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 cant 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
  elses sins, e.g.
• wireline-inspired rate controllers that fail to
  regulate all contending flows
• inefficiencies cause by auto rate adaptation
• etc.