Managing TCP Connections in Dynamic Spectrum Access Based Wireless LANs Ashwini Kumar Prof. Kang...
-
date post
21-Dec-2015 -
Category
Documents
-
view
220 -
download
1
Transcript of Managing TCP Connections in Dynamic Spectrum Access Based Wireless LANs Ashwini Kumar Prof. Kang...
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
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
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