Managing TCP Connections in Dynamic Spectrum Access Based Wireless LANs

Ashwini Kumar Prof. Kang G. Shin

Overview

1. Introduction 2. Motivation & Challenges3. Main Contribution: DSASync

i. DSASync at Link Layer (DSASync_LL)ii. DSASync at TCP Layer (DSASync_TCP)

4. Evaluation5. Future Work

2/20

Dynamic Spectrum Access

• Communication increasingly becoming wireless and mobile, but– Wireless spectrum is a limited and shared resource– Side-effects: overcrowding, interference increase

• Dynamic Spectrum Access (DSA): Opportunistic wireless communication on licensed bands– Aims to solve spectrum-usage inefficiency &

shortage– Still evolving

3/20

4/20

Why DSA Can Be Effective?

[[Source: Shared Spectrum Company][[Source: New America Foundation]

Motivation

• WLANs mainly deployed as edge networks– Connections are from wireless client to cloud

• DSA is an inherently disruptive technology: blackout period (TFP)

5/20

B1

B2

T1 T2 T3 T4 T5 T6 T7 T8 Time

Raw

Cap

acity Sensing PU Access Channel-switchCapacity change

→ DSA contributes to capacity & delay fluctuations→ Device-centric QoS provisioning insufficient for end-to-end connections

Challenges

• Efficient monitoring/response mechanism to mitigate effect of DSA-related events

• Transparent to ongoing connections– End-to-end semantics of TCP must not be violated

• Ease of configuration/deployment– No changes must be introduced in wired cloud – No need to recompile/re-link of existing protocols

6/20

DSASync Overview

• No restrictions on the DSA protocol• Centralized operation at BS• Key concepts: caching + traffic-shaping

7/20

Wired Network (WN)

Corresponding Host (CH)

Base Station (BS)

Spectrum-agile Host (SH)

DSAN

DSASync

DSASync Architecture

• Logically a link layer component• But affects the transport layer, executes at BS• Key Advantage: TCP semantics maintained, no protocol modification

necessary - uses only existing TCP hooks

8/20

Application

Transport

Routing

Link/MAC

Physical

DSASync_TCP

DSASync_LL

DSASync Module

DSASync at Link Layer (DSASync_LL)

• Passive monitoring & estimation unit for DSA parameters – E.g., fsense(i), tsense(i), fsense(DSAN), tswitch(DSAN), gON(PU), etc– Uses MAC/PHY events or historical averages– Establishes if Transmission Freeze Period (TFP) is active

• Needed by DSASync_TCP component

• In implementation, usually encapsulated within the MAC

9/20

DSASync at TCP Layer (DSASync_TCP)

• Sniffs incoming/outgoing packets• Maintains per connection state, e.g., seq. nos. & last ACK

seen

10/20

CH-SH (Ingress) traffic manager

Capacity change manager

DSASync_TCP SH-CH (Egress) traffic manager

CH-SH (Ingress) Traffic Manager (DSASync_TCP_CH-SH)

11/20

Advt. 0 rwin to all CHs

Advt. 0 rwin for conn.

Start

Packet p received?

TFP going on?

Put p to transmit queue

Buffer p Buffer < thresh?

Conn. rwin filling up?

Yes

No

No

Yes

No

Yes

No

Yes

SH-CH (Egress) Traffic Manager DSASync_TCP_SH-CH

12/20

• Smoothens outgoing flow to mask DSA disruptions – Estimate outgoing data-rate D(i)– α(i) = 1-(TFPavg/ΔT), β(i) = max(α(i), αmin)

– Effective data rate, Deff(i) = β(i)D(i)

• Algorithm to empty queue at “smoothed rate”• Further optimization, from O(N) to O(1) FCFS

dequeue scheme

Capacity Change Manager (DSASync_TCP_CAP)

13/20

• Exploits built-in TCP congestion control– Executed when existing traffic suddenly

unsustainable – Force timeout or trigger fast retransmit

(recovery) by sending duplicate ACKs to CHs

Evaluation

14/20

• Implementation: Basic DSA protocol in 802.11 (MadWifi), PU emulation using MadWifi+Click– DSASync kernel module runs at the router

• Metrics: goodput, delay, jitter

• Testbed: infrastructure edge WLAN (6 clients)– Channel = 36, def. PHY capacity = 24Mbps, buffer capacity =

500MB– TCP Reno: initial TCP send & recv. window is 256KB– αmin = 0.5, Bhigh = 500MB, Blow = 400MB– Def. PU utilization = 20%, sensing overhead = 5%

Results: Overhead

15/20

• Overhead characterization:– Compare overhead with 802.11 (no DSA

overhead)– Avg. 1.9% reduction in throughput– End-to-end delay increase around 1.1ms

Microbenchmarks

16/20

• CH-SH (ingress) traffic benefitted most: 74% improvement, low retrans. overhead (0.018Mbps)

• SH-CH (egress) traffic improvement 10%

Microbenchmarks

17/20

• End-to-end delay variation lower for SH-CH (egress) traffic • DSASync makes SH-CH connection resilient

Microbenchmarks

18/20

• PHY capacity reduced by 50% at 5s

• Distributed DSASync agents useful?

Macrobenchmarks

19/20

• 4 TCP streams on each client – total 24 concurrent connections

• Trends similar to microbenchmarks

• Improvements even greater: 102% for CH-SH (ingress) direction

Future Work

20/20

• Evaluation on a large scale testbed

• Extend DSASync for UDP– Motivation: UDP streams carry most of the QoS-

sensitive multimedia traffic today – Challenge: stateless protocol implies no built-in

hooks to control the connection

Questions?