210 likes | 309 Views
Managing TCP Connections in Dynamic Spectrum Access Based Wireless LANs. Ashwini Kumar Prof. Kang G. Shin. Overview. Introduction Motivation & Challenges Main Contribution: DSASync DSASync at Link Layer (DSASync_LL) DSASync at TCP Layer (DSASync_TCP) Evaluation Future Work .
E N D
Managing TCP Connections in Dynamic Spectrum Access Based Wireless LANs • AshwiniKumar • Prof. Kang G. Shin
Overview • Introduction • Motivation & Challenges • Main Contribution: DSASync • DSASync at Link Layer (DSASync_LL) • DSASync at TCP Layer (DSASync_TCP) • Evaluation • Future Work
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
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) Sensing PU Access Channel-switch Capacity change B1 Raw Capacity • DSA contributes tocapacity & delay fluctuations • Device-centric QoS provisioning insufficient for end-to-end connections B2 Time T1 T2 T3 T4 T5 T6 T7 T8
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
DSASync Overview • No restrictions on the DSA protocol • Centralized operation at BS • Key concepts: caching + traffic-shaping Corresponding Host (CH) DSAN Base Station (BS) DSASync Wired Network (WN) Spectrum-agile Host (SH)
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 Application DSASync_TCP Transport Routing DSASync_LL Link/MAC DSASync Module Physical
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
DSASync at TCP Layer (DSASync_TCP) • Sniffs incoming/outgoing packets • Maintains per connection state, e.g., seq. nos. & last ACK seen CH-SH (Ingress) traffic manager SH-CH (Egress) traffic manager DSASync_TCP Capacity change manager
CH-SH (Ingress) Traffic Manager (DSASync_TCP_CH-SH) Start Packet p received? No Advt. 0 rwin for conn. Yes Yes Conn. rwin filling up? TFP going on? No No Put p to transmit queue Yes Buffer < thresh? Yes Buffer p Advt. 0 rwin to all CHs No
SH-CH (Egress) Traffic Manager DSASync_TCP_SH-CH • 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) • 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 • 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 • 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 • CH-SH (ingress) traffic benefitted most: 74% improvement, low retrans. overhead (0.018Mbps) • SH-CH (egress) traffic improvement 10%
Microbenchmarks • End-to-end delay variation lower for SH-CH (egress) traffic • DSASync makes SH-CH connection resilient
Microbenchmarks • PHY capacity reduced by 50% at 5s • Distributed DSASync agents useful?
Macrobenchmarks • 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 • 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