Bandwidth Estimation in Broadband Access Networks

1
Bandwidth Estimation in Broadband Access Networks

• Karthik Lakshminarayanan
• UC Berkeley
• Venkat Padmanabhan and Jitu Padhye
• Microsoft Research

2
Motivation

• Lot of research on bandwidth estimation
• capacity
• available bandwidth
• Most evaluation restricted to Internet2 paths
• What about cable modems, DSL, wireless?
• last-hops for most of home networks
• growing in size

3
A Couple of Questions

• Why bandwidth estimation?
• maybe available bandwidth, but why capacity?
• Do these techniques work in the Internet paths in
  the first place?

4
Contributions

• Identify characteristics of broadband networks
  that pose challenges
• Evaluate these problems by performing experiments
  on real testbeds
• Propose ProbeGap, a new technique that partially
  addresses some of these problems

5
Outline

• Preliminaries and Background
• Broadband Network Issues
• ProbeGap
• Experimental Results

6
Definitions

• Capacity Bandwidth of the narrow link

n1
n3
n5
n2
R
S
n4
7
Definitions

• Available BW headroom on the tight link

n1
Narrow link
n3
n5
n2
R
S
n4

• In general capacity ! avail bw ! TCP tput

8
Earlier Tools Capacity Estimation

• Packet-pair based
• multi-modality of the packet pair spacing
• dominant mode may not correspond to capacity
• pathrate sophisticated filtering
• Relationship between packet size and delay
• such as pathchar, clink
• might not work as well as packet-pair based

9
Earlier Tools Avail-BW Estimation

• Packet rate method (PRM)
• train of packets sent different rates
• different charateristics depending on whether
  rate is greater/lesser than avail-bw
• pathload, TOPP, PTR, pathchirp
• Packet gap method (PGM)
• Relies on spacing of packet pairs at the tight
  link
• Requires estimation of capacity
• Spruce, IGI, Delphi

10
PGM Tools Illustration

• Spruce send a Poisson process of packet pairs
• for correctness set intra-pair gap ?in to
  psize/capacity
• To prevent intrusiveness, choose a large
  inter-pair gap

inter-pair gap
Bottleneck
Acknowledgement Content in this slide stolen
from Dina Katabis talk
11
Outline

• Preliminaries and Background
• Broadband Network Issues
• ProbeGap
• Experimental Results

12
Broadband Network Issues

• Traffic regulation
• cable modem
• Non-FIFO scheduling and contention
• cable modem, 802.11 wireless networks
• Multi-rate links
• 802.11 wireless networks

13
I. Traffic Regulation

• Assumption well-defined notion of raw bandwidth
  that indicates maximum rate
• Cases where assumption breaks
• cable modems have token bucket rate limiters
• e.g. raw bandwidth of DOCSIS compliant cable
  modem is 27Mbps (down), 2.5Mbps (up) customers
  get much less
• token bucket parameters are not publicly known
• Implications
• Need to distinguish between raw link bandwidth
  and maximum available rate for a sustained
  transfer
• What do the capacity tools measure anyway?

14
II. Non-FIFO Scheduling

• Assumption all packets are served FIFO
• queueing delay proportional to number of bytes
  already in queue
• cross-traffic packet size is immaterial
• Cases where assumption breaks
• 802.11 networks, cable uplink are non-FIFO
• MAC might impose per-frame fairness constraints

15
II. Non-FIFO Scheduling Implications

• Hard for packets to go back-to-back under high
  load ? underestimate capacity
• Delay might not be commensurate with
  cross-traffic ? overestimate avail-bw
• Might end up measuring fair share
• Per-frame scheduling (802.11/cable modem uplink)
  ? estimate depends on CT packet size
• MAC contention inefficiencies ? estimate might
  depend on number of stations

16
III. Multi-rate Links

• Assumption all packets are sent at same rate
  over the narrow/tight link
• Cases where assumption breaks
• multi-rate in 802.11 e.g. 802.11b allows radio
  to switch between 1, 2, 5.5 and 11 Mbps
• transmission rate based on channel quality
• per-frame fairness

17
III. Multi-rate Links Implications

• How does one interpret a capacity estimate?
• conditioned on sender rate
• Burstiness may affect tools
• CT at a lower rate appears as large burst
• most tools work assume a fluid model of CT
• e.g. pathload would not observe clear increasing
  trends in OWDs

18
Motivations Re-visited

• If MAC were fair, do we still need to estimate
  avail-bw and capacity?
• Applications
• quick initial ramp up without affecting CT to go
  down to their fair share
• admission control in 802.11-based digital A/V
  network can a new stream be admitted without
  affecting existing traffic?

19
Outline

• Preliminaries and Background
• Broadband Network Issues
• ProbeGap
• Experimental Results

20
ProbeGap

• Goal estimate avail-bw in last-hop link
• Basic idea estimate the fraction time the link
  is idle by probing for gaps
• assumes that capacity is known
• Overview
• send Poisson-spaced 20-byte (lightweight) probes
• compute OWD of the probes
• large OWD ? wait in the queue
• small OWD ? free link

21
ProbeGap

• Knee ? fraction of time the channel is idle

22
ProbeGap

• Knee-detection
• intuitively, the point of inflection
• robust to measurement errors, outliers
• ProbeGap behaviour
• more robust to packet-level contention, and
  bursty CT
• not entirely immune to non-FIFO effects
• susceptible to delay variations on other links
• ProbeGap is not an alternative to other tools
• how to use it with other tools ? future work

23
Outline

• Preliminaries and Background
• Broadband Network Issues
• ProbeGap
• Experimental Results

24
Measurement Setup

• Goal Evaluate the performance on one hop only
  (i.e. the last hop) no wide-area paths
• Cable-modem testbed
• experimental cable network (at MSR)
• two cable connections from same CMTS allows
  direct measurements
• control over token bucket parameters
• place measurement hosts close to the cable modem
  head end
• few commercial cable hosts

25
Measurement Setup

• Wireless testbed
• 6 identical machines with 802.11 a/b/g card
• experiments in 802.11a
• Tools
• capacity pathrate
• avail-bw pathload (PRM), Spruce (PGM)
• ProbeGap
• udpload UDP Poisson CT w/ diff packet sizes

26
Validation Methodology

• Capacity
• we knew the true results to compare against
• validate by sending UDP streams at high rates
• calibrate for different packet sizes
• Available bandwidth
• CT under our control (little external traffic)
• Compute true avail-bw as maximum UDP stream
  that can be sent without affecting CT
• Performed after each experiment

27
Impact of Token Bucket in Cable Modem

• Parameters
• Raw channel capacity 27 Mbps
• Token bucket rate 6Mbps
• Token depth 9600 bytes
• Capacity For all CT lt 6Mbps, pathrate estimated
  capacity as 26 Mbps
• token bucket depth was large enough
• this is the true raw link speed
• but perhaps, useless to applications

28
Impact of Token Bucket in Cable Modem

• Avail-bw pathload suffers from overestimation

29
Impact of Token Bucket in Cable Modem

• Avail-bw Spruce requires capacity as input!
• also suffers from overestimation biased by lost
  probes

30
Impact of Packet Sizes in 802.11

• Cumulative maximum achievable througput
• increases with packet size
• not with number of communicating pairs of hosts

31
Impact of Contention-based 802.11 MAC

• Parameters
• Channel rate 6Mbps
• Max sustainable UDP throughput 5.2Mbps
• Capacity Pathrate produces a consistent estimate
  of 5.1-5.5Mbps

32
Impact of Contention-based 802.11 MAC

• Parameters
• Channel rate 6Mbps
• Max sustainable UDP throughput 5.2Mbps
• CT 1-4 Mbps
• Packet sizes 300, 1472 bytes
• Validation
• validation experiment done with 300,1472 byte
  packets
• pathload 300B probes ? compared with 300 byte
  probe
• spruce 1472B probes ? compared with 1472 byte
  probe

33
Impact of Contention-based 802.11 MAC

• pathload overestimates at high CT since it gets
  the fair share
• spruce overestimates when the CT packet size is
  300 bytes (recall spruce uses 1472 byte pkts)
• probegap does much better at both packet sizes
• overestimates slightly at high CT

34
Impact of Multi-rate Links

• Setup
• measurement traffic A ? B at 54Mbps
• cross-traffic C ? D at 6Mbps
• Spruce
• reports zero avail-bw at high CT (4Mbps 300 byte
  pkts)
• overestimation with 1472-byte CT
• Pathload
• overestimates available bandwidth
• OWDs are messed up due to varying pkt sizes

35
Impact of Multi-rate Links

• Pathload owd sequence has few large jumps rather
  than uniform increase

36
Summary

• Last hop networks such as cable modem and
  wireless networks deviate from normal assumptions
• Show that popular capacity and
  available-bandwidth estimation tools dont work
  very well
• Revisit assumptions regarding measurement studies
  from time-to-time