_COS-598A, Spring 2017, Kyle Jamieson_

L3: SampleRate (Chapter 3)
===

#### Indoor Network Measurements
- 45-node indoor wireless testbed
- Mesh topology
- Linux Soekris router with Atheros 802.11a/b/g card
- RTS/CTS protocol disabled
- Link-level acknowledgements enabled
- Use a **quiet** 802.11 channel
- Throughput experiments

#### Difference from theory: Many intermediate delivery rates exist (Figure 3-2, middle)
- Indoor, 802.11g; vary the bit rate over \\(45^2 ~= 2,000\\) possible links.
	- Note that most of the 24 Mbit/s links are not operating at 24 Mbit/s, and there are many such links.  Similar trends for other bit rates.
		- From previous graphs we would expect very few intermediate links, but that’s not how it works in practice.
		- Contradicts theoretical packetized throughput prediction!
	- Bit rate adaptation algorithms must cope

#### Difference from theory: Does faster always mean more loss?  (Figure 3-3)
- Experiment: one sender at a time in indoor network, 1500 byte
  packets, everyone else listens, *all* links
- 9 Mbit/s vs 6 Mbit/s (*upper right*): 9 works well only if 6 works well.  Both use BPSK, same modulation, but different channel coding.
- 6 Mbit/s vs 1 Mbit/s (*upper left*): Some links are better with the newer but faster 6 Mbit/s 802.11g OFDM, some work better with the older but slower 1 Mbit/s 802.11b DSSS.
- Similar trends in newer work with differing numbers of spatial streams

#### *How rapidly does bit rate adaptation need to adapt?* (Figures 3-4, 3-5)
- Delivery probability fluctuates rapidly (Figure 3-4), some links more bursty than others with similar average delivery probabilities.
- Each node sends interleaved 1500 byte packets at 6, 9, 12, 18, 24 Mbit/s; divide time into *t* millisecond intervals over which an "omniscient" algorithm chooses the best throughput bit rate.
	- Diminishing gains past \\(t=10\\) second adaptation interval
	- What about \\(t < 50\\) ms (not shown) -- some measurement studies claim the indoor wireless channel stays the same for about 30 ms, so there *might* be more room for improvement (later work with walking speed mobility affirms this).

#### *Can SNR predict delivery probability?* (Figures 3-6, 3-7)
- Figure 3-6: Each graph = one bit rate, each point = one link
	- x axis?  *average* SNR
	- y axis?  *average* delivery rate
	- Takeaway: Can't choose a useful S/N threshold that predicts delivery
- Figure 3-7: Each graph = one *receiver*, each point = one sender (all 1 Mbit/s rate)
	- This factors out receive radio hardware variability, better relationship
	- Multipath different on different links though.
- Across all links, picking a S/N threshold that predicts delivery is hard, so SampleRate abandons this.
	- But subsequent work showed benefits (Effective SNR, will read later).
 
#### Classifying links' bitrate-loss relationships (Figures 3-8, 3-9)
- Three example links shown here (Figure 3-8).
- *Grey bar*: ideal throughput; *black bar*: actual throughput achieved,
  averaged across time.
- Definitions (count of types in Figure 3-9): 
  - *Steep*: All links either > 90% delivery, or < 10% delivery
  - *Gradual*: Gradually more loss at higher bitrates **but** the best-performing bitrate = highest bitrate with < 50% loss
  - *Lossy*: Best link has delivery rate well below < 50%
- Implications:
  - For steep bitrates, can just pick **highest loss-free** bitrate;
    but this is disasterous when gradual links exist.
  - For lossy links, need to increase bitrate **despite** loss.

#### ARF, Adaptive ARF (Chapter 4)
- Original WaveLAN-II (Lucent) algorithm, circa 1996
- Definion: *packet* is new data, may have several *transmissions* (attempts to send the packet).
- **Algorithm**
  - *State*: current bit rate, # consecutive successful transmissions 
  - Start at highest
  - **Okay** packet is one that required just one transmission.  Maintain `okay_transmit_count`
  - **Step down** if no ack after `num_xmits`
  - **Step up** if 10 consecutive "okay" transmissions occur (this is
    called a *probe*)    
- What would ARF do:
  - On the steep links?  + (Start at 11, fail, pick 5.5)
  - ..gradual links?  -- (Get stuck at high rate sometimes, don't step down
    until complete failure.  Once you step up in a Gradual link, less likely to step down immediately than in a Steep link, less loss @ 11 for Gradual, since you need four **consecutive** frame losses to step down.)
  - ..lossy links?  -- (Once you step down, you may not step up, and get stuck
    at low rate sometimes.)
- *Adaptive ARF*: Even on steep link, ARF sends probes.  **Adapt** step-up
    parameter (10 transmits), **double** every time increase bitrate and subsequent
    packet fails.
  - Backoff penalty high for high 802.11g bit rates, so helps.
  - Will AARF do better on gradual? (no)  Lossy? (no)
  
#### ONOE
  - Atsushi Onoe (engineer at Sony/Japan)
  - Highest bitrate with < 50% loss
    - makes sense in 802.11b: 11/2=5.5; 5.5/2 ~= 2; 2/2=1, less sense
      in 802.11a (36,24,18,12,9,6)
    - Maintain num_tx, num_tx_ok
    - Start at highest bit rate like ARF.
    
    - Each second on the wall clock:
      - if #1: if no successful transmits, step down
      - if #2: if less than 50% success rate, step down
      - if #3: if less than 10% success rate, lose credit
      - if #4: if greater than 90% success rate, gain a credit, step up
        if you have more than 10 credits.

  - what would ONOE do on the steep links? +
    1st sec. 11
    2nd sec. 5.5
    3rd sec. 5.5
    ...
    10th sec. 11
    11th sec 5.5
    12th sec 5.5

  - what would ONOE do on the gradual links? +
    1st sec. 11
    2nd sec. 5.5 (line 3)
    3rd sec. 5.5
    NO probe up to 11 periodically every 10 sec. (credits don't accum)

  - what would ONOE do on the lossy links?  --
    1st sec 11
    2nd sec 5.5
    3rd sec 2
    4th sec 1

### SampleRate (Chapter 5)

- Basic idea: consider time to send a packet.  Track:
	- Average send time @ bitrate (empirically measure)
	- Lossless send time @ bitrate (constant)

- Choose bitrate with least average send time
- Probe some other bitrates
	- Probing happens one every 10 packets
	- Probe a *candidate set* of rates having a **lossless transmission time less than the current average transmission time**

- Expire information that is more than 10 seconds old

#### Slide: Measuring time to send a packet
- Any problems with this?
  - What about backoff time before transmissions apart from the last
    one?
  - What about intervening transmissions from other nodes?
  - Not counted in this calculation, but impacts all bit rates about
    the same.


#### Slide: SampleRate in operation
- Notation: packets(transmissions)@rate
- upper dest: fails at rate = 11, perfect at rate = 5.5
  - 4(16)@11, switch to 5.5, 100(100)@5.5
  - why won't it try rate = 2, 1? (lossless@2 and 1 > average@5.5)
  - when will it next try rate = 11?  (10 sec, after
      `remove_stale_results` runs)
- lower dest: one retry at rate = 11, 90% 0 retries, 10% 1 retry at
    rate = 5.5
  - 9(18)@11, 1(1)@5.5, switch to 5.5, 9(9)@5.5
  - why probe 5.5?  (since 2976 < 3761)
  - why switch to 5.5? (since 3235 < 3761)

### Evaluation (Chapter 6)

#### ARF mostly chooses correct bit rate (Figure 6-2)
- x-axis: static-best throughput
- y-axis: **hypothetical** -- take the bitrate that ARF chose most
    often, plot throughput of static-best for that bitrate
- **Conclusion:** ARF chose right bitrate most of the time!  **Hypothesis:** ARF spends too much time trying other bit rates.

#### Slide: Indoor 802.11a performance (Figure 6-1)
- ARF spends too much time trying other bit rates, especially on the **steep** links

#### Discussion
- What about interference from other 802.11 traffic?
- What about mobility?
- What about SNR-based rate adaptation?
	- Cellular mobile networks use SNR to adapt
	- Why do we have trouble applying it for 802.11?
	- More recent work in this area by Halperin (SIGCOMM 2010)