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?
