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

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, 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 University of Southern California

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

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

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

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

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

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

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