Estimating Bandwidth of Mobile UsersSept 2003

Rohit KapoorCSD, UCLA

Estimating Bandwidth of Mobile UsersMobile, Wireless UserDifferent possible wireless interfacesBluetooth, 802.11, 1xRTT, GPRS etcDifferent bandwidthsLast hop bandwidth can change with handoffDetermine bandwidth of mobile userUseful to application servers: Video, TCPUseful to ISPs

Capacity EstimationFundamental Problem: Estimate bottleneck capacity in an Internet pathPhysical capacity different from available bandwidth

Estimation should work end-to-endAssume no help from routers

Packet DispersionPrevious work mostly based on packet dispersion Packet Dispersion (pairs or trains)

Previous WorkPacket PairsSelect highest mode of capacity distribution derived from PP samples (Crovella)Assumes that distribution will give capacity in correspondence to highest modeLais potential bandwidth filtering Both of these techniques assume unimodal distributionPaxson showed distribution can be multimodalPacket tailgatingPathcharCalculates capacity for every link

Previous WorkDovrolis WorkExplained under/over estimation of capacityMethodologyFirst send packet pairsIf multimodal, send packet trainsStill no satisfactory solution!!!Most techniques too complicated, time/bw-consuming, inaccurate and prone to choice of parametersNever tested on wireless

Problems due to Cross-TrafficCross-traffic (CT) serviced between PP packetsSmaller CT packet size => More likely

This leads to under-estimation of Capacity

Problems (cont)Compression of the packet pairLarger CT packet size => More likely

Over-estimation of CapacityPost Narrow (20Mbps)Narrow Link (10Mbps)Packet QueuedPacket Not QueuedTTT < T

Fundamental Queuing ObservationObservationWhen PP dispersion over-estimates capacityFirst packet of PP must queue after a bottleneck linkFirst packet of PP must experience Cross Traffic (CT) induced queuing delayWhen PP dispersion under-estimates capacityPackets from cross-traffic are serviced between the two PP packetsSecond packet of PP must experience CT induced queuing delay

Fundamental ObservationObservation (also proved)When PP dispersion over-estimates capacityFirst packet of PP must queue after a bottleneck linkWhen PP dispersion under-estimates capacityPackets of cross-traffic are serviced between the two PP packetsSecond packet of PP must experience CT induced queuing delayBoth expansion and compression of dispersion involve queuing

Observation (cont)Expansion or CompressionSum of delays of PP packets > Minimum sum of delaysWhen Minimum sum of delays?Both packets do not suffer CT induced queuingIf we can get one sample with no CT induced queuingDispersion is not distorted, gives right capacitySample can easily be identified since the sum of delays is the minimum

Our Methodology: CapProbePP really has two pieces of informationDispersion of packetsDelay of packetsCombines both pieces of informationCalculate delay sum for each packet pair sampleDispersion at minimum delay sum reflects capacity Capacity

RequirementsSufficient but not necessary requirementAt least one PP sample where both packets experience no CT induced queuing delay.How realistic is this requirement?Internet is reactive (mostly TCP): high chance of some probe packets not being queuedTo validate, we performed extensive experimentsSimulations and measurementsOnly cases where such samples are not obtained is when cross-traffic is UDP and very intensive (>75%)

CapProbeStrength of CapProbeOnly one sample not affected by queuing is neededSimplicity of CapProbeOnly 2 values (minimum delay sum and dispersion) need storageOne simple comparison operation per sampleEven simplest of earlier schemes (highest mode) requires much more storage and processing

ExperimentsSimulations, Internet, Internet2 (Abilene), WirelessCross-traffic options: TCP (responsive), CBR (non-responsive), LRD (Pareto)Wireless technologies tested: Bluetooth, IEEE 802.11, 1xRTTPersistent, non-persistent cross-traffic

Simulations6-hop path: capacities {10, 7.5, 5.5, 4, 6, 8} Mbps PP pkt size = 200 bytes, CT pkt size = 1000 bytesPersistent TCP Cross-Traffic

SimulationsPP pkt size = 500 bytes, CT pkt size = 500 bytesNon-Persistent TCP Cross-Traffic

SimulationsNon-Persistent UDP CBR Cross-Traffic

Only case where CapProbe does not workUDP (non-responsive), extremely intensiveNo correct samples are obtained

Internet MeasurementsEach experiment500 PP at 0.5s intervals100 experiments for each {Internet path, nature of CT, narrow link capacity}OS also induces inaccuracy

Wireless MeasurementsExperiments for 802.11b, Bluetooth, 1xRTTClean, noisy channelsBad channel retransmission larger dispersions lower estimated capacityResults for Bluetooth-interfered 802.11b, TCP cross-traffichttp://www.uninett.no/wlan/throughput.html : IP throughput of 802.11b is around 6Mbps

Probability of Obtaining SampleAssuming PP samples arrive in a Poisson mannerProduct of probabilitiesNo queue in front of first packet: p(0) = 1 / No CT packets enter between the two packets (worst case)Only dependent on arrival processAnalyzed with Poisson Cross-Trafficp = p(0) * e- L/ = (1 /) * e- L/

Sample FrequencyAverage number of Samples required to obtain the no-queuing sample Analytical

Poisson cross traffic is a bad caseBursty Internet traffic has more windows

Sample FrequencySimulations: mix of TCP, UDP, Pareto cross trafficResults for number of samples required

InternetIn most experiments, first 20 samples contained the minimum delay sample

ConclusionCapProbeSimple capacity estimation methodWorks accurately across a wide range of scenariosOnly cases where it does not estimate accuratelyNon-responsive intensive CTThis is a failure of the packet dispersion paradigm

Useful applicationUse a passive version of CapProbe with modern TCP versions, such as Westwood