<?xml-model href='http://www.tei-c.org/release/xml/tei/custom/schema/relaxng/tei_all.rng' schematypens='http://relaxng.org/ns/structure/1.0'?><TEI xmlns="http://www.tei-c.org/ns/1.0">
	<teiHeader>
		<fileDesc>
			<titleStmt><title level='a'>Softening the Impact of Collisions in Contention Resolution</title></titleStmt>
			<publicationStmt>
				<publisher>Springer</publisher>
				<date>10/20/2024</date>
			</publicationStmt>
			<sourceDesc>
				<bibl> 
					<idno type="par_id">10573833</idno>
					<idno type="doi"></idno>
					
					<author>U Biswas</author><author>T Chakraborty</author><author>M Young</author>
				</bibl>
			</sourceDesc>
		</fileDesc>
		<profileDesc>
			<abstract><ab><![CDATA[Contention resolution addresses the problem of coordinating access to a shared communication channel. Time is discretized into synchronized slots, and a packet can be sent in any slot. If no packet is sent, then the slot is empty; if a single packet is sent, then it is successful; and when multiple packets are sent at the same time, a collision occurs, resulting in the failure of the corresponding transmissions. In each slot, every packet receives ternary channel feedback indicating whether the current slot is empty, successful, or a collision.Much of the prior work on contention resolution has focused on optimizing the makespan, which is the number of slots required for all packets to succeed. However, in many modern systems, collisions are also costly in terms of the time they incur, which existing contention-resolution algorithms do not address.In this paper, we design and analyze a randomized algorithm, COLLISION-AVERSION BACKOFF (CAB), that optimizes both the makespan and the collision cost. We consider the static case where an unknown n → 2 packets are initially present in the system, and each collision has a known cost C, where 1 ↑ C ↑ n ω for a known constant ω → 0. With error probability polynomially small in n, CAB guarantees that all packets succeed with makespan and a total expected collision cost of Õ(n ↓ C). We give a lower bound for the class of fair algorithms: where, in each slot, every packet executing the fair algorithm sends with the same probability (and the probability may change from slot to slot). Our lower bound is asymptotically tight up to a poly(log n)-factor for sufficiently large C.]]></ab></abstract>
		</profileDesc>
	</teiHeader>
	<text><body xmlns="http://www.tei-c.org/ns/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink">
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1">Introduction</head><p>Contention resolution addresses the fundamental challenge of coordinating access by devices to a shared resource, which is typically modeled as a multiple access channel. Introduced with the development of ALOHA in the early 1970s <ref type="bibr">[1]</ref>, the problem of contention resolution remains relevant in WiFi networks <ref type="bibr">[16]</ref>, cellular networks <ref type="bibr">[32]</ref>, and shared-memory systems <ref type="bibr">[8,</ref><ref type="bibr">24]</ref>.</p><p>Our problem is described as follows. There are n &#8594; 2 devices present at the start of the system, each with a packet to send on the shared channel, and n is a priori unknown. For ease of presentation, we adopt a slight abuse of language by referring to packets sending themselves (rather than referring to devices that send packets). Time proceeds in discrete, synchronized slots, and each slot has size that can accommodate the transmission of a packet. For any fixed slot, the channel provides ternary feedback, allowing each packet to learn whether 0 packets were sent, 1 packet was sent (a success), or 2+ packets were sent (a collision). Sending on the channel is performed in a distributed fashion; that is, a priori there is no central scheduler or coordinator. Traditionally, the contention-resolution problem focuses on minimizing the number of slots until all n packets succeed, which is referred to as the makespan.</p><p>However, in many modern systems, collisions also have a significant impact on performance. In the standard cost model, each collision can be viewed as a wasted slot that increases the makespan by 1, since no packet can succeed. Yet, in many settings, a collision wastes more than a single slot, and we denote this cost by C. <ref type="foot">3</ref> This cost can vary widely across different systems. In intermittently-connected mobile wireless networks <ref type="bibr">[36]</ref>, failed communication due to a collision may result in the sender having to wait until the intended receiver is again within transmission range. For WiFi networks, a collision may consume time proportional to the packet size <ref type="bibr">[6]</ref>. In shared memory systems, concurrent access to the same memory location can result in delay proportional to the number of contending processes <ref type="bibr">[8]</ref>. Thus, makespan gives only part of the performance picture, since collisions may add to the time until all packets succeed.</p><p>In this work, we account for the cost of collisions, in addition to the makespan. As we discuss later (see Section 3), existing contention-resolution algorithms do not perform well in this setting. For instance, randomized binary exponential backoff (BEB) <ref type="bibr">[30]</ref>, arguably the most popular of all contention-resolution algorithms, incurs a collision cost of &#949;(n C), where C is the cost of a single collision. New ideas are needed to achieve better performance in this model.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.1">Model and Notation</head><p>Our work addresses the case where an n &#8594; 2 number of packets are active at the start of the system. There is no known upper bound on n a priori, and packets do not have identifiers. A packet is active if it is executing a protocol; otherwise, the packet has terminated. Each packet must be successfully sent in a distributed fashion (i.e., there is no scheduler or central authority) on a multiple access channel, which we now describe.</p><p>Multiple Access Channel. Time is divided into disjoint slots, where each slot is sized to accommodate a single packet. In any slot, a packet may send itself or it may listen. For any fixed slot, if no packet is sent, then the slot is empty; if a single packet is sent, then it is successful; and if two or more packets are sent, then there it is a collision and none of these packets is successful. A packet that transmits in a slot immediately learns of success or failure; if it succeeds, the packet terminates immediately. Any packet that is listening to a slot, learns which of these three cases occurred; this is the standard ternary feedback model. Likewise, for any slot, a packet that is sending can also determine the channel feedback; either the packet succeeded (which it learns in the slot) or it failed (from which the packet infers a collision occurred). Packets cannot send messages to each other, and no other feedback is provided by the channel.</p><p>Metrics. A well-known measure of performance in prior work is the makespan, which is the number of slots required for all n packets to succeed. An equivalent metric in the static case is, throughput, which is defined as the time for n successes divided by the makespan.</p><p>In our model, each collision incurs a known cost of C, where 1 &#8593; C &#8593; n &#969; , for a known constant &#969;&#8594; 0. <ref type="foot">4</ref> Given a contention-resolution algorithm, the pertinent costs are: (i) the collision cost, which is the number of collisions multiplied by C, and (ii) the makespan. Often we refer to "cost", by which we mean the maximum of (i) and (ii), unless specified otherwise.</p><p>Notation. Throughout this manuscript, lg(&#8226;) refers to logarithm base 2, and ln(&#8226;) refers to the natural logarithm. We use log y (x) to denote (log(x)) y , and we use poly(x) to denote x y for some constant y &#8594; 1. The notation &#213; denotes the omission of a poly(log n) factor. We say an event occurs with high probability (w.h.p.) in n (or simply "with high probability") if it occurs with probability at least 1 &#8596; O(1/n c ), for any tunable constant c &#8594; 1.</p><p>For any random variable X, we say that w.h.p. the expected value E[X] &#8593; x if, when tallying the events in the expected value calculation, the sum total probability of those events where X &gt; x is O(1/n c ) for any tunable constant c &#8594; 1. In our analysis, the expected collision cost holds so long as the subroutine DIAGNOSIS (described later) gives correct feedback to the packets, and this occurs with high probability.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.2">Our Results</head><p>We design and analyze a new algorithm, COLLISION-AVERSION BACKOFF (CAB), that solves the static contention resolution problem with high-probability bounds on makespan and the expected collision cost. The following theorems provide our formal result. How does this compare with prior results? For starters, consider SAWTOOTH-BACKOFF (STB), which w.h.p. has an asymptotically-optimal makespan of &#977;(n), but incurs &#949;(n) collisions. The expected cost for CAB is superior to STB when C is at least polylogarithmic in n. In Section 1.3, we elaborate on how our result fits with previous work on contention resolution.</p><p>In a well-known lower bound in the standard cost model, Willard <ref type="bibr">[35]</ref> defines and argues about fair algorithms. These are algorithms where, in a fixed slot, every active packet sends with the same probability (and the probability may change from slot to slot). Our lower bound applies to fair algorithms as follows.</p><p>Theorem 2. Any fair algorithm that w.h.p. has a makespan of &#213;(n &#8595; C) has w.h.p. an expected collision cost of &#949;(n</p><p>Since CAB is fair and guarantees w.h.p. a makespan of &#213;(n &#8595; C), our upper bound is asymptotically tight up to a poly(log n)-factor for sufficiently large C. A more general form of our lower bound is given in Section 4, along with additional discussion.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.3">Why Care About Collision Costs?</head><p>Here, we discuss the potential value of our result and exploring beyond the standard cost model for contention resolution.</p><p>A Simple Answer. Prior contention-resolution algorithms that optimize for makespan suffer from many collisions. For example, arguably the most famous backoff algorithm is BEB (despite its sub-optimal makespan <ref type="bibr">[9]</ref>), which has &#949;(n) collisions. Similarly, STB has asymptotically-optimal makespan, but also suffers &#949;(n) collisions <ref type="bibr">[6]</ref>. Thus, these algorithms have cost &#952;(n + nC). In contrast, the expected completion time for CAB is &#213;(n &#8595; C), which is superior whenever C = poly(log n).</p><p>In the extreme, even a hypothetical algorithm that suffers (say, w.h.p.) a single collision would do poorly by comparison if collisions are sufficiently costly. Specifically, such an algorithm pays C, which is asymptotically worse than the expected completion time of CAB for C = &#960;(n 2 ).</p><p>Perhaps the above is reasonable motivation (we think it is), but why not also consider the cost of successes? <ref type="foot">5</ref> Below, we argue that reducing collision cost remains important, and that adding a non-unit cost for successes does not seem interesting from a theory perspective.</p><p>Connecting to the Standard Cost Model. Let us temporarily consider the implications of a cost model where a success and a collision each have cost P &#8594; 1. In the standard cost model P = 1. In WiFi networks, both costs are also roughly equal, where P &#8599; 1 <ref type="bibr">[6]</ref>.</p><p>In this context, reconsider STB's performance. Since, n packets must succeed, a cost of at least nP is unavoidable, and the additional &#977;(nP ) cost from collisions becomes (asymptotically) unimportant. (Indeed, any algorithm must pay at least nP for successes; given this unavoidable cost, it does not seem interesting from a theory perspective to consider a model where a success costs far more than a collision, since the cost from successes would dominate.) Likewise, CAB must also pay at least nP , which is (asymptotically) no better than STB.</p><p>Does reducing collision costs matter here? Yes, and the value of our result is best viewed via throughput (recall Section 1.1). STB has cn collisions, for some constant c &gt; 0, and (ignoring empty slots) its throughput is less than nP/(nP + (cn)P ) &lt; 1/(1 + c) &lt; 1 &#8596; 1/c; that is, the throughput is bounded away from 1 by a constant amount. Doing a similar calculation for CAB, there is nP cost for n packets to succeed, plus O(n &#8595; P ), which accounts for collisions and empty slots. Thus, the expected throughput is E[nP/T ] where T is the completion time. Since,</p><p>Thus, for the standard cost model, with P = 1, our result is (unsurprisingly) not an improvement. However, as P grows, our result provides better throughput in expectation, approaching 1. There are settings where we expect P to be large, such as: wireless networks where P can be commensurate with packet size, routing in mobile networks where communication failure increases latency <ref type="bibr">[36]</ref>, and shared memory systems where concurrent access to the same memory location by multiple processes results in delay <ref type="bibr">[8]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2">Related Work</head><p>There is a large body of work on the static case for contention resolution, where n packets arrive together and initiate the contention resolution algorithm; this is often referred to as the static or batched-arrival setting. Bender et al. <ref type="bibr">[9]</ref> analyze the makespan for BEB, as well as other backoff algorithms; surprisingly, they show that BEB has sub-optimal makespan.</p><p>An optimal backoff algorithm is STB <ref type="bibr">[26,</ref><ref type="bibr">28]</ref>. Since we borrow from STB to create one of our subroutines (discussed further in Section 3.1), so we describe it here. Informally, STB works by executing over a doubly-nested loop, where the outer loop sets the current window size w to be double the one used in the preceding outer loop. Additionally, for each such window, the inner loop executes over a run of lg w windows of decreasing size: w, w/2, w/4, ..., 1. For each window, every packet chooses a slot uniformly at random (u.a.r.) to send in.</p><p>The static setting has drawn attention from other angles. Bender et al. <ref type="bibr">[10]</ref> examines a model where packets have different sizes under the binary feedback model. Anderton et al. <ref type="bibr">[6]</ref> provide experimental results and argue that packet size should be incorporated into the definition of makespan, since collisions tend to cost time proportional to packet size.</p><p>To the best of our knowledge, our work is the first to propose an algorithm for minimizing collision cost, and so it makes sense to start with the static setting. However, we note the dynamic setting has been addressed (under the standard cost model), where packet arrival times are governed by a stochastic process (see the survey by Chlebus <ref type="bibr">[20]</ref>). Another direction that the research community has pursued is the application of adversarial queueing theory (AQT) <ref type="bibr">[17]</ref> to contention resolution; for examples, see <ref type="bibr">[22,</ref><ref type="bibr">21,</ref><ref type="bibr">3,</ref><ref type="bibr">2]</ref>. Under the AQT setting, packet arrival times are dictated by an adversary, but typically subject to constraints on the rate of packet injection and how closely in time (how bursty) these arrivals may be scheduled. Even more challenging, there is a growing literature addressing the case where packet arrival times are set by an unconstrained adversary; see <ref type="bibr">[23,</ref><ref type="bibr">14,</ref><ref type="bibr">25]</ref>. Recent work in this area addresses additional challenges facing modern networks, such as energy efficiency <ref type="bibr">[29,</ref><ref type="bibr">15]</ref>, malicious disruption of the shared channel <ref type="bibr">[12,</ref><ref type="bibr">7,</ref><ref type="bibr">31,</ref><ref type="bibr">19,</ref><ref type="bibr">5,</ref><ref type="bibr">4]</ref>, and the ability to have a limited number of concurrent transmission succeed <ref type="bibr">[13]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3">Technical Overview for Upper Bound</head><p>Due to space constraints, our proofs for the upper bound are provided in Section A of our appendix. However, we do reference some well-known inequalities based on the Taylor series that are omitted here, but can be found in Section A.1.</p><p>Here, we present an overview of our analysis, with the aim of imparting some intuition the design choices behind CAB, as well as highlighting the novelty of our approach. To this end, we first consider two natural-but ultimately flawed-ideas for solving our problem.</p><p>Straw Man 1. An immediate question is: Why can we not use a prior contention-resolution algorithm to solve our problem? For example, in the static setting, a well-known backoff algorithm, such BEB guarantees w.h.p. that all packets succeed with makespan &#977;(n log n) <ref type="bibr">[9]</ref>. Under BEB, the packets execute over a sequence of disjoint windows, where window i &#8594; 0 consists of 2 i contiguous slots. Every active packet sends in a slot chosen u.a.r. from the current window. Unfortunately, a constant fraction of slots in each window i &#8593; lg(n) + O(1) will be collisions. Each collision imposes a cost of C leading to a collision cost of &#949;(nC).</p><p>&#8600; &#8771;</p><p>Despite yielding a poor result, this straw man provides three useful insights. First, we cannot have packets start with a "small" window, since this leads to many collisions. Many backoff algorithms start with a small window, and will not yield good performance for this same reason. Second, we should seek to better (asymptotically) balance the costs of makespan and collisions. Under BEB, these costs are highly unbalanced, being &#977;(n log n) and &#949;(nC), respectively. We may trade off between makespan and collision cost; that is, we can make our windows larger, which increases our makespan, in order to dilute the probability of collisions.</p><p>Third, a window of size &#977;(n &#8595; C) seems to align with these first two insights; that is, it appears to asymptotically balance makspan and collision cost. To understand the latter claim, suppose that in each slot, every packet sends with probability &#977;(1/(n &#8595; C)). We can argue (informally) that, for any fixed slot, the probability of any two packets colliding is at least</p><p>Thus, over n &#8595; C slots in the window, the expected number of collisions is</p><p>and each collision has cost C, so the expected collision cost is O(n &#8595; C). Of course, this informal analysis falls short, since collisions may involve more than two packets, and we have not shown that all n packets can succeed over this single window (they cannot). Yet, this insight offers us hope that we can outperform prior backoff algorithms by achieving costs that are o(nC).</p><p>How should we find a window of &#977;(n &#8595; C)? Since n is unknown a priori, we cannot simply instruct packets to start with that window size. It is also clear from the above discussion that we cannot grow the window to this size using prior backoff algorithms. This obstacle leads us to our second straw man.</p><p>Straw Man 2. Perhaps we can estimate n and then start directly with a window of size &#977;(n &#8595; C). A well-known "folklore" algorithm for estimating n is the following. In each slot i &#8594; 0, each packet sends with probability 1/2 i ; otherwise, the packet listens. This algorithm, along with improvements to the quality of the estimation, is explored by Jurdzinski et al. <ref type="bibr">[29]</ref>, but we sketch why it works here.</p><p>Intuitively, when i is small, say a constant, then the probability of an empty slot is very small: (1 &#8596; 1/2 &#949;(1) ) n &#8593; e &#8594;&#949;(n) by Fact 1(a). However, once i = lg(n), then the probability of an empty slot is a constant: 1) by Fact 1(c). In other words, once a packet witnesses an empty slot, it can infer that its sending probability is &#977;(1/n), and thus the reciprocal yields an estimate of n to within a constant factor.</p><p>At first glance, it may seem that we can estimate n, and then proceed to send packets in a window of size &#977;(n &#8595; C). Unfortunately, for each slot i &#8593; lg(n), this algorithm (and others like it) will likely incur a collision, and thus the expected collision cost is &#949;(C log n). To see why this is a problem, suppose that C = n 4 . This implies that the expected collision cost is &#949;(C) = &#949;(n 4 ), while the makespan is at best O(n</p><p>That is, there is an n-factor discrepancy between the expected collision cost and makespan, which grows worse for larger values of C; this approach is not trading off well between these two metrics.</p><p>&#8600; &#8771; Even though the above algorithm racks up a large collision cost, it highlights how channel feedback can provide useful hints. If packets are less aggressive with their sending, we can reduce collisions while still receiving feedback that lets us reach our desired window size of &#977;(n &#8595; C).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.1">Our Approach</head><p>Motivating Sample Size. Hoping to avoid the problems illustrated in our discussion above, all packets begin with an initial current window size that can be "large"; the exact size we motivate momentarily. Recall that we aim for packets to tune their sending probability to be &#977;(1/(n &#8595; C)), so we are aiming for a window size of &#977;(n &#8595; C). However, this must be achieved with low expected collision cost. To do this, the packets execute over a sample of s slots. For each slot in the sample, every packet sends with probability 1 divided by the current window size, and monitors the channel feedback.</p><p>What does this channel feedback from the sample tell us? Suppose we have reached our desired window size of</p><p>Then, the window size may be large relative to n, and so we should expect empty slots to occur frequently, while successes do occur, but less often; the probability of success is approximately n</p><p>To correctly diagnose w.h.p. (using a Chernoff bound) that w = &#977;(n &#8595; C), we rely on receiving &#977;(log n) successes. This dictates our sample size to be s</p><p>The details behind this intuition are given in Section A.2 of our appendix, where we show that samples of size &#977;( &#8595; C log(n)) are sufficient to make correct decisions that tune the window size to be &#977;(n &#8595; C). Furthermore, in Section A.3 of our appendix, we show that the corresponding cost from this tuning is &#213;(n &#8595; C).</p><p>Motivating Initial Window Size. Suppose we are not at our desired window size. Then, the feedback from sampling tells us what to do. If our current window size is too large (i.e., our sending probability is too low), then the number of successes will be "small", since most slots are empty, and we should decrease our window size. Else, if the current window size is too small, (i.e., our sending probability is too high) then the number of successes is again "small", since most slots are collisions, and we should increase the window size. But wait, in the latter case, can we tolerate the cost of the resulting collisions? In the worse case, the entire sample might consist of collisions, resulting in a potentially large cost of s C = &#977;(C 3/2 log n).</p><p>We remedy this problem by setting our initial window size to be C. Then, the probability of a collision in a fixed slot is approximately n 2 (1/C 2 ) and so the expected cost is roughly</p><p>This reasoning is formalized in Lemma 13 of our appendix.</p><p>In light of the above, we emphasize that CAB does not avoid all collisions; in fact, many collisions may occur when the collision cost is "small" (i.e., C &#8593; n). However, as the collision cost grows "larger" (i.e., C &gt; n), CAB expresses an increasing aversion to collisions by having packets tune their respective sending probabilities such that we expect o(1) collisions per sample. The cost analysis for sampling is given in Section A.3 of our appendix.</p><p>Borrowing from Sawtooth Backoff. By using sampling, ultimately a window size of &#977;(n &#8595; C) is reached. At this point, every active packet executes the analog of the final run of STB (recall Section 2). Specifically, each packet sends with probability p = &#977;(1/(n &#8595; C)), which we show is sufficient to have at least half of the active packets succeed (see <ref type="bibr">Lemma 20)</ref>. Then, the window is halved, and the process repeats where the remaining packets send with probability p/2. This halving process continues until all packets succeed. By the sum of a geometric series, the number of slots in this process is O(n &#8595; C). Informally, the expected collision cost per slot is roughly n</p><p>, and thus O(n &#8595; C) over all slots in the window. The analysis of cost is provided in Section A.4 of our appendix. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.2">Our Algorithm and Overview of Analysis</head><p>This section describes and gives intuition for CAB, whose pseudocode is given in Figure <ref type="figure">2</ref>. As stated in our model (Section 1.1), when a packet succeeds it terminates immediate; for ease of presentation, we omit this from our pseudocode.</p><p>From a high-level view, each packet keeps track of a current window size, wcur; this size is critical, as it dictates the per-slot sending probability of each packet, which is &#977;(1/wcur). Each packet keeps track of its own notion of a current window. However, in each slot, since every packet is either listening or sending (and, thus, learning whether the slot contained a success or a collision), all packets receive the same channel feedback and adjust their respective current window identically (stated formally in Lemma 8). Therefore, for ease of presentation, we refer only to a single current window.</p><p>Defining Ranges. In order to describe how CAB works, we define the six size ranges that the current window (or just "window" for short), wcur, can belong to during an execution.</p><p>These ranges are depicted in Figure <ref type="figure">1</ref>. We note that the particular constants in these ranges are not special; they are chosen for ease of analysis. To gain intuition, we now describe the events we expect to witness in the ROCK-BOTTOM, LOW, GOOD, and HIGH ranges when CAB executes; we defer an in-depth discussion of UNCERTAIN-LOW and UNCERTAIN-HIGH until the end of the next subsection.</p><p>The ROCK-BOTTOM range captures "tiny" window sizes, starting from 1 up to n &#8596; 1. In this range, the probability of sending exceeds 1/n, and we expect that most slots will be collisions. The next range is LOW, and it includes window sizes from n to just below 10n &#8595; C. This range represents a moderate increase in window size, allowing for more successes than ROCK-BOTTOM, although there can still be many collisions. As discussed in Section 3.1, in ROCK-BOTTOM and in the bottom portion of LOW, we can afford to have an single sample consist entirely of collisions, since C = O(n) (see <ref type="bibr">Lemma 16)</ref>. However, lingering in these ranges would ultimately lead to sub-optimal expected collision cost.</p><p>The GOOD range spans from 200n &#8595; C to just below 10 3 n &#8595; C. In this range, the window sizes are sufficiently large that we expect o(1) collisions, along with handful of successes; notably, less successes than LOW. This turns out to be a "good" operating range for the algorithm, where the balance between collision costs and makespan is achieved, as discussed in Section 3 (i.e., our third insight after Straw Man 1).</p><p>The HIGH range covers window sizes from 10 5 n &#8595; C and above. In this range, the window sizes are very large, leading to a very low probability of collisions, which is good. However, there are also far-fewer successes compared to GOOD, which means that lingering in this range would lead to a sub-optimal number of slots until all packets succeed.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>COLLISION-AVERSION BACKOFF</head><p>1 Initial window size wcur &#8657; C 2 repeat 3 #successes, #collisions &#8657; 0 4 COLLECT-SAMPLE(C, wcur) 5 DIAGNOSIS(#successes, #collisions, wcur) 6 until true; 7 Function COLLECT-SAMPLE(C, wcur): 8 #successes &#8657; 0 9 #collision &#8657; 0 for slot i = 1 to d &#8595; C ln(wcur) do Send with probability 1/wcur; otherwise, listen if slot is a success then #successes++ else if slot is a collision then #collisions++ Function DIAGNOSIS(#successes, #collisions, wcur): if #successes &gt; 2d ln(wcur) 10 5 then if #successes &#8593; d ln(wcur) 20e then if #collisions &#8594; d &#8594; C ln(wcur) 8e 2 then 20 wcur &#8657; 2wcur else 22 Execute RUNDOWN (wcur) else wcur &#8657; 2wcur else if #collisions &#8594; d &#8594; C ln(wcur) 8e 2 then wcur &#8657; 2wcur else wcur &#8657; wcur/2 Function RUNDOWN(wcur): w 0 &#8657; wcur while wcur &#8594; 8 &#8595; C lg(w 0 ) do for each slot j = 1 to wcur do Send packet with probability 2/wcur wcur &#8657; wcur/2  . exactly what will happen, although we do prove that the algorithm is making "progress". We will elaborate on this further after describing our methods for sampling and interpreting channel feedback, which we address next.</p><p>Sampling and Diagnosing Feedback. CAB navigates these ranges by using two subroutines: COLLECT-SAMPLE and DIAGNOSIS. As motivated earlier in Section 3.1, a sample is a contiguous set of d &#8595; C ln(wcur) slots that are used by each packet to collected channel feedback. Specifically, under COLLECT-SAMPLE, in each slot of the sample, every packet sends independently with probability 1/wcur and records the result if it is a success or a collision.</p><p>Based on the number of successes and the number of collisions, DIAGNOSIS attempts to determine the range to which wcur belongs. We discuss these thresholds in order to give some intuition for how DIAGNOSIS is making this determination. To simplify the presentation, we omit discussion of UNCERTAIN-LOW and UNCERTAIN-HIGH until the end of this section. The process by which CAB homes in on the range to which wcur belongs is depicted in Figure <ref type="figure">3</ref>.</p><p>We begin with the first if-statement on Line 17. This line checks if the number of successes is at least a logarithmic amount (in wcur); if so, this indicates that wcur cannot be in the HIGH range, which would yield far fewer successes (see <ref type="bibr">Lemma 13)</ref>. Therefore, if meet the conditional on Line 17, it must be the case that wcur belongs to ROCK-BOTTOM, LOW, or GOOD.</p><p>Line 18 checks whether the number of successes falls below a "large" logarithmic amount; if not, then we are seeing a "large" number of successes that indicates wcur cannot be in ROCK-BOTTOM or in GOOD, and so must be in LOW (see <ref type="bibr">Lemma 10)</ref>. Otherwise, the number of successes falls below this logarithmic amount, indicating that wcur is in the ROCK-BOTTOM or in GOOD ranges. To discern between these two cases, Line 19 checks if the number of collisions exceeds d</p><p>, which indicates wcur &#8659; ROCK-BOTTOM (see Lemmas 6, 7, and 9). Otherwise, wcur falls within the GOOD and the job of DIAGNOSIS is complete -at this point, RUNDOWN will be executed.</p><p>How can an algorithm with low expected collision cost make a decision based on whether &#977;( &#8595; C log(wcur)) collisions occur? Recall that in this case, we are deciding between wcur &#8659; ROCK-BOTTOM and wcur &#8659; GOOD. We will only witness this number of collisions when wcur is in the ROCK-BOTTOM range, where C &#8593; n and so we can tolerate this cost. Otherwise, as described above, wcur &#8659; GOOD and the expected number of collisions is only &#213;(1/ &#8595; C) (see the discussion preceding Lemma 11 in our appendix).</p><p>The remaining portion of DIAGNOSIS starts with the else-statement on Line 25. This line is executed only if the conditional on Line 17 is not met; that is, we have very few successes. This can occur only if wcur &#8659; ROCK-BOTTOM or wcur &#8659; HIGH. The former case is (again) diagnosed be checking whether there are many collisions (Line 26) and, if so, the window is doubled; otherwise, we are in the latter case and the window is halved. Again, we only have many collisions if wcur is in the ROCK-BOTTOM or lower portion of the LOW ranges, where C &#8593; n and so we can tolerate this cost.</p><p>What about the uncertain ranges? In UNCERTAIN-LOW, a sample will contain enough successes to satisfy Line 17. However, it is unclear whether the number of successes will be "large" (if wcur is in the lower portion of UNCERTAIN-LOW) or "moderate" (if wcur is in the upper portion of UNCERTAIN-LOW). In the former case, we fail Line 18, while in the latter case, we satisfy Line 18. Despite this uncertainty, observe that we are nonetheless guaranteed to either double the window or execute RUNDOWN. Either of these outcomes count as progress, since either wcur moves closer to GOOD by doubling, or RUNDOWN is executed on a window of size &#977;(n &#8595; C) (in contrast, halving wcur would be counterproductive). The intuition behind UNCERTAIN-HIGH is similar. If wcur &#8659; HIGH, then we can show that the number of successes fails Line 17 (see <ref type="bibr">Lemma 13)</ref> and that, ultimately, we halve wcur. However, between GOOD and HIGH, this cannot be shown w.h.p.; it may hold if wcur is close to the lower end of HIGH, but not hold if wcur is close to the upper end of GOOD. So, instead, we argue that we either halve wcur or execute RUNDOWN. Either of these actions counts as progress, since either wcur moves closer to GOOD, or RUNDOWN is executed on a window of size &#977;(n &#8595; C). Ultimately, we are able to show the following key lemma (in Section A. <ref type="bibr">3</ref> of our appendix): Lemma 19. The executions of COLLECT-SAMPLE and DIAGNOSIS guarantee that w.h.p.: (i) RUNDOWN is executed within O( &#8595; C log 2 (n)) slots, and (ii) the total expected collision cost until that point is O</p><p>All Remaining Active Packets Succeed. The final subroutine, RUNDOWN, is executed once wcur = &#977;(n &#8595; C), and it allows all active packets to succeed. In each slot of wcur, every packet sends with probability 2/wcur. Otherwise, the current window size is halved and the remaining active packets repeat this process. This continues until the window size reaches &#977;(</p><p>, where the asymptotic equality holds by recalling that C = poly(n). Once this smallest window in the run is reached, O(log n) active packets remain. To finish these packets, CAB performs an additional &#977;(ln(n</p><p>, where any remaining active packet sends in each slot with probability &#977;(1/n &#8595; C). We prove the following lemmas (in Section A. <ref type="bibr">4</ref> of our appendix): Lemma 21. When RUNDOWN is executed, w.h.p. all packets succeed within O(n &#8595; C ln(n)) slots. Lemma 22. W.h.p. the expected collision cost for executing RUNDOWN is O(n &#8595; C ln(n)). Finally, our upper bound in Theorem 1 follows directly from Lemmas 19, 21, and 22.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4">Technical Overview for Lower Bound</head><p>In this section, we provide an overview of our argument, which focuses on placing a lower bound on the expected collision cost. Here, we highlight the key lemmas in our argument, and our full proofs are provided in Section B of our appendix. We consider only the set of slots, S, in the execution of any algorithm where at least two active packets remain, since we cannot have a collision with a single active packet. While we do not always make this explicit, but going forward, any slot t is assumed to implicitly belong to S.</p><p>Let pi(t) denote the probability that packet i sends in slot t. Note that, if a packet has terminated, its sending probability can be viewed as 0. For any fixed slot t, the contention in slot t is Con(t) = n i=1 pi(t); that is, the sum of the sending probabilities in that slot.</p><p>When Contention is High. We start by showing that any algorithm that has even a single slot t with Con(t) &gt; 2 must have &#949;(C) expected collision cost, which is one portion of our lower bound. This is done by deriving an expression for the probability of a collision in any fixed slot t as a function of Con(t), which is useful when Con(t) is "high" (see <ref type="bibr">Lemmas 23,</ref><ref type="bibr">24,</ref><ref type="bibr">and 25</ref> in Section B of our appendix).</p><p>When Contention is Low. What about an algorithm where all slots of the execution have "low" contention (i.e., Con(t) &#8593; 2)? Our previous expression is hard to work with in this case. So, we derive a different expression for the probability of a collision in a fixed slot t, which can be useful for small values of Con(t): Lemma 26. Fix any slot t and let Con(t) &#8593; 2. The probability of a collision in t is at least ( 1 110 ) Con(t) 2 &#8596; i pi(t) 2 . However, this expression requires some additional work to be deployed in our argument, as we now describe.</p><p>For any fixed slot t &#8659; S, let pmax(t) be the maximum sending probability of any packet in slot t. Similarly, let psec(t) &#8593; pmax(t) be the next-largest sending probability of any packet in slot t; note that psec(t) = pmax(t), if more than one packet sends with probability pmax(t).</p><p>Define &#949;(t) = psec(t)/pmax(t). Our analysis ignores any slot t where Con(t) = 0; that is, any slot where every packet has a sending probability of 0. We give such slots to any algorithm for "free"; that is, we do not include them in the cost of the execution. Thus, &#1009;(t) is always well-defined, since pmax(t) &gt; 0.</p><p>Why do we need &#1009;(t)? It captures a sense of "balance". For our purposes, the situation is most "unbalanced" when exactly one packet has non-zero sending probability, while all other packets have zero sending probability; that is, when the total value of Con(t) &gt; 0 is due to a single packet. Clearly, in such slots, there can be no collision and, correspondingly, &#1009;(t) = 0. In our argument, &#1009;(t) plays a key role in establishing the following: Lemma 27. For any fixed slot t, Con(t) 2 &#8596; i pi(t) 2 &#8594; &#1009;(t) Con(t) 2 /2. A natural extension of &#1009;(t) is &#949;min, which is the minimum &#1009;(t) over all slots t &#8659; S. As we show momentarily, our lower bound is parameterized by &#1009;min. The last component of our argument addresses the sum of the contention over all slots in S: Lemma 30. Any algorithm that guarantees w.h.p. that n packets succeed must w.h.p. have t&#8595;S Con(t) = &#949;(n). We can now establish a lower bound for this low-contention case: Lemma 31. Consider any algorithm A whose contention in any slot is at most 2 and guarantees w.h.p. a makespan of &#213;(n &#8595; C). W.h.p. the expected collision cost for A is &#949;(&#1009;minn &#8595; C).</p><p>Proof. Let X be a random variable that is |S| under the execution of A. Note that, since w.h.p. the makespan is &#213;(n &#8595; C), it must be the case that w.h.p. X = &#213;(n &#8595; C). By Lemma 30, we have:</p><p>for some constant c &gt; 0. Let Yt = 1 if slot t &#8659; S has a collision; otherwise, Yt = 0. By Lemmas 26 and 27:</p><p>where the second line follows from the definition of &#1009;min. The expected collision cost is:</p><p>By Jensen's inequality for convex functions, we have:</p><p>Finally, the expected cost is at least:</p><p>by Equations 8 and 9</p><p>by Equation <ref type="formula">7</ref>= &#949; &#1009;min n &#8595; C</p><p>where the second line follows by Equation <ref type="formula">7</ref>, which was defined with regard to S, and so can be compared to Equation <ref type="formula">8</ref>. The last line follows since w.h.p. X = &#213;(n &#8595; C).</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#8600; &#8771;</head><p>Given our analysis of the high-and low-contention cases, we have the following lower bound:</p><p>Theorem 4. Consider any algorithm that w.h.p. guarantees &#213;(n &#8595; C) makespan. Then, w.h.p., the expected collision cost for A is &#949;(min{C, &#1009;minn &#8595; C}).</p><p>What algorithms does our lower bound say something interesting about? We can start with our statement in Theorem 2. For a well-known lower bound with the standard cost model, Willard <ref type="bibr">[35]</ref> defines and argues about fair algorithms. These are algorithms where, in a fixed slot, every active packet sends with the same probability (and the probability may change from slot to slot). Fair algorithms have &#1009;min = 1, and for a sufficiently large collision cost-specifically, C = &#949;(n 2 )-the lower bound becomes &#949;(n &#8595; C). Given that CAB is fair and w.h.p. guarantees &#213;(n &#8595; C) makespan, we thus have a lower bound that is asymptotically tight to a poly(log n)-factor with our upper bound.</p><p>Our lower bound also applies in a similar way to a generalized notion of fairness, where the sending probabilities of any two packets are within some factor &#962; &gt; 0. For example, if &#962; = &#977;(1), then &#1009;min = &#977;(1). Indeed, we only need such &#962;-fairness between the two packets with the largest probabilities for our lower bound to apply, although our bound weakens as &#962; grows larger.</p><p>Another class of algorithms that our lower bound applies to is multiplicative weights update algorithms, where in each slot every packet updates its sending probability by a multiplicative factor based on channel feedback in the slot. Many of these algorithms are fair (such as <ref type="bibr">[18,</ref><ref type="bibr">11,</ref><ref type="bibr">34,</ref><ref type="bibr">33,</ref><ref type="bibr">31,</ref><ref type="bibr">7,</ref><ref type="bibr">13]</ref>), but not all are (such as <ref type="bibr">[11]</ref>). Our lower bound applies in a non-trivial way to all such algorithms; that is, &#1009;min &gt; 0 given the update rules.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5">Conclusion and Future Work</head><p>We considered a model for the problem contention resolution where each collision has cost C. Our algorithm, COLLISION-AVERSION BACKOFF, addresses the static case and guarantees w.h.p. that all packets succeed with makespan and expected collision cost that is &#213;(n &#8595; C). There are several directions for future work that are potentially interesting. First, we would like to extend this cost model to the dynamic setting (where packets may arrive over time) and design solutions. Many algorithms for the dynamic case break the packet arrivals into (mostly) disjoint batches; however, this requires periodic broadcasting that can cause collisions.</p><p>Second, for the lower bound, we believe (with some more work) that we can remove the poly(log n) factor. However, we would like to derive a more general lower bound. A significant challenge appears to be addressing algorithms that set up slots where exactly one packet has non-zero sending probability, while all others have zero sending probability. For example, an elected leader might "schedule" each packet their own exclusive slot in which to send (with probability 1). Since there can be no collisions after such a schedule is implemented, it seems a lower bound argument must demonstrate that establishing a schedule is costly.</p><p>Third, what if collisions are not fully dictated by the actions of packets? Some wireless settings are inherently "noisy", due to weather conditions, co-located networks, or faulty devices. Is there a sensible model for such settings and, if so, can we reduce the cost from collisions?</p><p>Proof. Fix a time slot t. Let pi denote the probability that packet i sends in slot t and number of packets at the beginning is m. The probability of collision in slot t is at most:</p><p>which proves the claim.</p><p>&#8600; &#8771;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>A.2 Correctness Analysis for DIAGNOSIS</head><p>In order to argue correctness for DIAGNOSIS, we give a case analysis for each of the ROCK-BOTTOM, LOW, GOOD, and HIGH ranges. In each case, we provide the necessary bounds on successes and collision per sample, which allows us to demonstrate that DIAGNOSIS correctly diagnoses the current range and performs the correct action. We start with Lemmas 2, 3, 4, and 5, which establish lower and upper bounds on the number of successes in the ranges of LOW, GOOD, and HIGH. Proof. Let Xi be an independent random variable where Xi = 1 when i-th slot in w contains a success, and Xi = 0 otherwise.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>P r(Xi</head><p>X k , then the expected number of success: Proof. Let Xi be an independent random variable where Xi = 1 when i-th slot in w contains a success, and Xi = 0 otherwise.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>P r(Xi</head><p>.</p><p>Let X k be an independent random variable where X k = 1 when k-th slot in the sample contains a success, and X k = 0 otherwise. The expected number of successes in the sample is: Xi, and note by the above that E[X] &#8594; d ln(wcur) be . By Theorem 3, with &#962; = 1/2, we have:</p><p>n d &#8593; where d &#8596; can be an arbitrarily large constant, so long as d is sufficiently large.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#8600; &#8771;</head><p>The next two lemmas pertain to the range of ROCK-BOTTOM. Lemma 6 shows that, when the window size is O(n/ log n), the entire sample will consist of collisions. Unlike many of our other arguments, we cannot employ a Chernoff to establish this fact. Lemma 7 handles the remainder of the ROCK-BOTTOM range, showing that much of the sample will consist of collisions.</p><p>Lemma 6. Suppose that 1 &#8593; wcur &#8593; n c ln n and n is sufficiently large and c &#8594; 1 is a constant. Then, with probability at least 1 &#8596; 1/n d &#8593; , the entire sample consists of collisions, where d &#8596; depends on sufficiently large c.</p><p>Proof. For any fixed slot, the probability of a collision is at least 1 minus the probability of a success, minus the probability of that the slot is empty. In other words, the probability of a collision is at least:</p><p>for n sufficiently large which yields the claim.</p><p>&#8600; &#8771; Lemma 7. Suppose n c ln n &lt; wcur &#8593; n, where c &#8594; 1 is any constant. Then, with probability at least 1&#8596;1/n d &#8593; , the sample contains at least d &#8595; C ln(wcur)/(8e 2 ) slots consists of collisions, where d &#8596; is an arbitrarily large constant depending on sufficiently large d.</p><p>Proof. Let the indicator random variable Xi = 1 if the i-th slot of the d &#8595; C ln(wcur) slots contains a collision; otherwise, let Xi = 0. The probability of a collision is lower bounded as follows.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>P r(Xi</head><p>cur e &#8594;2n/wcur by Fact 1(c)</p><p>Xi. The expected number of collisions in the sample of d &#8595; C ln(wcur) slots is:</p><p>by linearity of expectation.</p><p>We then employ Theorem 3, with &#962; = 1/2, to obtain:</p><p>where d &#8596; can be an arbitrarily large constant, so long as d is sufficiently large.</p><p>&#8600; &#8771; Lemma 8. Under DIAGNOSIS, all packets witness the same number of empty slots, successes, and collisions.</p><p>Proof. In each slot, a packet is either sending or listening. First, consider the case where at least one packet sends. Each such sending packet knows whether it succeeded (i.e., a success) or it failed (i.e., a collision). Each non-sending packet listens and hears the success (i.e., a success) or the failure (i.e., a collision). Second, if no packet sends, then every packet is listening and hears the same thing: silence. Therefore, in all cases, each packet witnesses the same outcome of the slot.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#8600; &#8771;</head><p>Lemma 8 guarantees that all packets are always in the same window (or have the same sending probability) when executing DIAGNOSIS, and they always take the same action in an execution of DIAGNOSIS. The following lemmas establish that DIAGNOSIS takes the correct action in each execution. ), if wcur &#8659; ROCK-BOTTOM, then all packets double their window, where d &#8596; is an arbitrarily large constant depending on sufficiently large d.</p><p>Proof. We do a case analysis. For the first case, consider that wcur &#8659; [1, n/(c ln n)) for some sufficient large constant c &#8594; 1. By Lemma 6, with probability at least 1 &#8596; n &#8594;d &#8593; , all slots in the sample contain a collision. Therefore, w.h.p., the if-statement on Line 17 is not entered and, instead, the matching else-statement on Line 25 is entered. Since all sample slots are collisions, the if-statement on Line 26 is entered, and the window doubles.</p><p>For the second case, consider wcur &#8659; [n/(c ln n), n). Either we (a) enter the first if-statement on Line 17, or we (b) enter the matching else-statement on Line 25.</p><p>&#8226; Subcase (a). If the second if-statement on Line 18 is entered, then we note by Lemma 7, w.h.p., that we have at least</p><p>C ln(wcur)/(8e 2 ) collisions, which means we double the window, as desired. Otherwise, we execute Line 23, and the window doubles.</p><p>&#8226; Subcase (b). By Lemma 7 w.h.p. we have at least d &#8595; C ln(wcur)/(8e 2 ) collisions, which means we enter the ifstatement on Line 26 and double the window.</p><p>In both cases, the packet doubles its window.</p><p>&#8600; &#8771;</p><p>), if wcur &#8659; LOW, then all packets double their window, where d &#8596; is an arbitrarily large constant depending on sufficiently large d.</p><p>Proof. By Lemma 5 with b = 10, for w such that n &#8593; w &lt; 10n &#8595; C, with probability at least 1 &#8596; n &#8594;d &#8593; the number of successes exceeds d 20e ln(wcur). Therefore, the first if-statement on Line 17 is entered, but the next if-statement on Line 18 is not. Thus, Line 23 will be executed and so the window will double, as claimed.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>&#8600; &#8771;</head><p>The following lemma places an upper bound on the number of collisions when the window is at least 200n &#8595; C. This allows us to argue that when we are in the GOOD and HIGH ranges, we avoid executing the lines in DIAGNOSIS that would double the window.</p><p>We note that the next lemma gives a very loose upper bound on the number of collisions. In fact, if we expected even a single collision in this range, our claimed upper bound would not hold. The careful reader will note that (in our proof) the expected number of collisions is &#213;(1/ &#8595; C); however, a loose upper bound that holds with high probability is sufficient to construct the rules for DIAGNOSIS. Proof. By Lemma 1, the probability of a collision in a slot is at most 2n 2 p 2 (1&#8594;np) , where p &#8593; 1/(200n &#8595; C). Plugging in, we obtain that the probability of collision is upper bounded by:</p><p>Xi. The expected number of collisions in the sample of d &#8595; C ln wcur slots is: , so Line 17 will be true. For the remaining lines that may be executed-Lines 18 to 24-we either double the window (due to many collisions) or execute RUNDOWN, as claimed.</p><p>&#8600; &#8771; Lemma 15. With probability at least 1 &#8596; O(1/n d &#8593; ), if wcur &#8659; UNCERTAIN-HIGH, then either the window halves or RUNDOWN is executed, where d &#8596; is an arbitrarily large constant depending on sufficiently large d.</p><p>Proof. We prove this by ruling out all the ways in which wcur could (incorrectly) double.</p><p>Unlike our argument for wcur &#8659; GOOD, we cannot guarantee that Line 17 will be executed, since our window might be large, say just shy of 10 5 n &#8595; C, (recall that UNCERTAIN-HIGH = [10 3 n &#8595; C, 10 5 n &#8595; C)), and we cannot prove a sufficient number of successes. However, if we proceed to Line 25, then by Lemma 11, the number of collisions is at most (d/90) ln(wcur), which means there are not enough collisions to meet the if-statement condition on 26, and thus the window will not be doubled here.</p><p>Another way in which the window can (incorrectly) double is via Line 23. However, we only execute Line 23 if Line 18 fails to hold; that is, in the case that the sample contains more than than d ln(wcur) 20e successes. However, by Lemma 4 with a = 10 3 (the part of UNCERTAIN-HIGH where successes are most likely), the sample contains at most 2d ln(wcur) 10 3</p><p>&lt; d ln(wcur) 20e successes, and so Line 18 will indeed execute. Finally, in the case that Line 18 executes, we do not have enough collisions to satisfy Line 26, again by Lemma 11. Thus, the window cannot double via <ref type="bibr">Line 20</ref> We have shown that, when wcur &#8659; UNCERTAIN-HIGH, either the window must halve, or RUNDOWN is executed, as claimed.</p><p>&#8600; &#8771;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>A.3 Cost Analysis for COLLECT-SAMPLE</head><p>The next lemmas establish bounds on the expected collision cost for executing COLLECT-SAMPLE. To this end, we employ the results established above, which hold with probability at least 1 &#8596; 1/n d &#8593; for as large a constant d &#8596; &#8594; 1 as we wish, depending only on sufficiently large d. Thus, the results in this section also hold with this high probability, and for ease of presentation, we omit this from our technical lemma statements and arguments. Proof. We prove this using a case analysis.</p><p>Case 1: C &#8594; 2n. This captures all of ROCK-BOTTOM and the left endpoint of LOW. Here, even if the entire sample consists of collisions, then the cost is at most:</p><p>Case 2: C &gt; 2n. With high probability, wcur &#8659; LOW only if the initial window lies in LOW. (With high probability, we cannot have started in ROCK-BOTTOM and moved up, since we start at a window of size C &gt; n in this case.)</p><p>The probability of a collision is maximized when the window is smallest; that is, when the window has size C (which is the initial window size), since w.h.p. the window only increases (given that we are in LOW). By Lemma 1, the probability of a collision is at most:</p><p>where the equation from Lemma 1 is applicable, since p = 1/C &lt; 1/(2n). Thus, expected cost is at most: C , the probability of a collision is at most:</p><p>Xi. The expected number of collisions in the sample of d &#8595; C ln(wcur) slots is:</p><p>Thus, the expected collision cost is at most:</p><p>Proof. For HIGH, by using Lemma 1, we plug in the value m = n (number of packets) and p &#8593; 1 10 5 n &#8593; C (sending probability). The probability of a collision is at most:</p><p>since this value is largest for p = Xi. The expected number of collisions in the sample of d &#8595; C ln(wcur) slots is:</p><p>Thus, multiplying by C, we obtain that the expected collision cost is at most O( &#8595; C ln(n)). &#8600; &#8771; Lemma 19. The executions of COLLECT-SAMPLE and DIAGNOSIS guarantee that: (i) RUNDOWN is executed within O( &#8595; C log 2 (n)) slots, and (ii) the total expected collision cost until that point is O n &#8595; C log 2 (n) . Proof. We first bound the number of slots, and then we bound the expected collision cost. (i) Bound on Number of Slots. By Lemmas 9, 10, and 14, DIAGNOSIS correctly doubles the window or executes RUN-DOWN. Similarly, by Lemmas 13 and 15, DIAGNOSIS correctly halves the window or executes RUNDOWN. Therefore, DIAGNOSIS is always making progress towards reaching GOOD. How many window halvings or doublings are required to reach GOOD? We start at an initial window of size C, and either GOOD is smaller-in which case, we must perform O(log(C)) = O(log(n)) samples-or larger-in which case, we must again perform O(log(n &#8595; C)) = O(log(n)) samples. Thus, the number of slots until GOOD is reached is at most the sample size multiplied by this number of samples, which is O( &#8595; C log 2 (n)). Then, by Lemma 12, RUNDOWN is executed. (ii) Bound on Expected Collision Cost. Let Si denote the collision cost for sample i when executing DIAGNOSIS, where i = 1, ..., h, where h = O(log(n)) is the number of samples. Denote the total cost from collisions by S = h i=1 Si. By Lemmas 16, 17, and 18, we have:</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>A.4 Correctness and Cost Analysis for RUNDOWN</head><p>A single execution of lines 33 to 35 in RUNDOWN of COLLISION-AVERSION BACKOFF is called a run. In any run, all packets operate over a window of size wcur and send themselves in each slot with probability 2/wcur. At the end of the window, those packets that succeeded will terminate, while the remaining packets will carry on into the next window, which has size wcur/2.</p><p>Our overall goal is to show that (roughly) a logarithmic in n runs are sufficient for all packets to succeed. To this end, our next lemma (below) argues that in each run at least half of the remaining packets succeed. Again, throughout this section, our results hold with a tunable probability of error that is polynomially small in n, and we omit this in our lemma statements. Lemma 20. Suppose m packets execute a window of RUNDOWN (wcur), where &#966; ln n &#8593; m &#8593; n, &#966; &#8594; 1 is a positive constant, and wcur &#8594; 8m &#8595; C. Then, at least m/2 packets succeed.</p><p>Proof. Fix a packet and calculate the probability of failing over the entire window of size 8m &#8595; C. To do so, note that the probability that this packet succeeds in a fixed slot is: (i) the probability that the packet sends in this slot, multiplied by (ii) the probability that all other m &#8596; 1 packets remain silent. That is:</p><p>Thus, the probability of failure in the slot is:</p><p>It follows that the probability of failing over all wcur slots is: </p><p>For i = 1, ..., m, let the indicator random variable Xi = 1 if packet i fails over the entire window; otherwise, let Xi = 0.</p><p>We let X = m i=1 Xi, and note that: . This implies that, over these j windows in the run, n packets will be reduced to no more than n/2 j = O(log n) packets by the final window. Therefore, we have the following corollary. For the remainder of this section, all of the lemmas that we invoke hold with high probability in n, and thus we omit this from most of our lemmas statements and arguments. We are now able to prove correctness and an upper bound on the number of slots incurred by RUNDOWN. Repeating this c ln(w0) &#8593; c ln(n) times guarantees that all remaining packets succeed with an error bound of at most: . By Lemma 20, in each window of a run, the number of packets is reduced by at least a factor of 2, and then the window size halves. That is, at the start of the i-th run, the number of packets is mi &#8593; n/2 i and the window size is wi = w0/2 i , for i &#8594; 0.</p><p>We employ Lemma 1, where pi = 2/wi. We have that the expected number of collisions over a window of size wi in the run is at most: </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>A.5 Analysis of COLLISION-AVERSION BACKOFF</head><p>We wrap up our analysis of CAB by calling on our main lemmas from the previous sections.</p><p>Theorem 1 W.h.p. COLLISION-AVERSION BACKOFF guarantees that all packets succeed, the makespan is O(n &#8595; C log(n)), and the expected collision cost is O(n &#8595; C log 2 (n)). Proof. By Lemma 19, over the course of executing COLLECT-SAMPLE and DIAGNOSIS, w.h.p. CAB executes over O( &#8595; C log 2 (n)) slots and the expected collision cost is O(n &#8595; C log 2 (n)). By Lemmas 21 and 22,w.h.p. when RUNDOWN is executed in CAB, all packets succeed within O(n &#8595; C ln(n)) slots and the expected collision cost is O(n &#8595; C ln(n)). Therefore, CAB guarantees that all packets succeed, the makespan is O(n &#8595; C log(n)), and the expected collision cost is O(n &#8595; C log 2 (n)). &#8600; &#8771;</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>B Lower Bound</head><p>We consider only the set of slots, S, in the execution of any algorithm where at least two active packets remain, since we cannot have a collision with a single active packet. While we do not always make this explicit, but going forward, any slot t is assumed to implicitly belong to S. Let pi(t) denote the probability that packet i sends in slot t. Note that, if a packet has terminated, its sending probability can be viewed as 0. For any fixed slot t, the contention in slot t is Con(t) = n i=1 pi(t); that is, the sum of the sending probabilities in that slot.</p><p>We begin by arguing that any algorithm with contention exceeding 2 in any slot must incur an expected collision cost of &#949;(C). We do this by deriving an upper bound on the probability of (i) a success and (ii) an empty slot, as a function of contention. In turn, this provides a lower bound on the probability of a collision that is useful when contention exceeds 2, allowing us to show &#949;(C) expected cost in Lemma 25.</p><p>Lemma 23. Fix any slot t. The probability of a success is at most e&#8226;Con (t)  e Con(t) .</p></div><note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="3" xml:id="foot_0"><p>We may also view C as an upper bound on the cost of a collision if there is some variance.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="4" xml:id="foot_1"><p>Note that knowing C and &#969; implies only a lower (not upper) bound on n.</p></note>
			<note xmlns="http://www.tei-c.org/ns/1.0" place="foot" n="5" xml:id="foot_2"><p>Empty slots do not seem to warrant such consideration since, by definition, nothing is happening in such slots, and so a per-cost of 1 makes sense.</p></note>
		</body>
		</text>
</TEI>
