Transcript WINLAB-IAB-Talk-2003-05

Challenges and Opportunities in Providing Wireless Data Services
in 3G Wireless Networks
Dr. Sanjoy Paul
([email protected])
Research Director
Bell Laboratories Research
Lucent Technologies
Outline
 Introduction
 Challenges in
o Consumer segment
 Data Performance
o Enterprise segment
 Security
 Conclusion
2
Introduction
3
Wireless Standards Evolution to 3G
1G
2G
“2.5G”
3G/ IMT-2000 Capable
Existing Spectrum
Analog
AMPS
IS-95-A/
cdmaOne
IS-95-B/
cdmaOne
New Spectrum
cdma2000 1X (1.25 MHz)
cdma2000 3X (5 MHz)
1XEV DO: HDR (1.25 MHz)
136 HS
EDGE
IS-136
TDMA
TACS
GSM GPRS
EDGE
GSM
HSCSD
UMTS
(WCDMA)
4
Current State of the Wireless Market






Primarily voice-centric; limited data usage
Penetration level for mobile subscribers continues to increase
“Minutes of use” per subscriber continues to rise
Average Revenue Per User (ARPU) is flat or declining
3G voice alone is not enough to justify huge investments in
3G technology and licenses
Need for High Speed Data (HSD) in wireless networks is
clear
5
Western Europe Wireless Subscribers
In 2005 W. Europe will have over 410M mobile subscribers
reaching 87% penetration
105%
W. Europe Subs
End Year Penetration
400.00
87%
80%
90%
75%
300.00
60%
200.00
45%
30%
100.00
Penetration
Millions of Subs
500.00
15%
-
0%
95
W. Europe
Subs (Millions)
Net Adds (Millions)
% Change y/o/y
End Year Penetration
Incremental Penetration
96
97
98
99
00
01
02
03
04
05
1995 1996 1997 1998
1999
2000
2001
2002
2003
2004
2005
22.0 34.1 53.1 166.5 261.3 309.6 349.3 372.6 388.8 400.5 411.5
7.9 12.0 19.0 113.4
94.8
48.3
39.7
23.2
16.2
11.7
11.0
56% 54% 56% 214%
57%
19%
13%
7%
4%
3%
3%
5%
8% 12%
37%
57%
67%
76%
80%
83%
85%
87%
3%
4%
25%
21%
10%
8%
5%
3%
2%
2%
The Strategies Group W. European Data Bank – March 2003
6
U.S. Wireless Subscribers
U.S. wireless penetration is likely to reach 57.7% by year end
2003 with nearly 167 million subscribers
Millions
180
160
140
60%
52%
120
100
80
60
Subscribers
50%
Ending Penetration
40%
30%
20%
40
20
0
10%
0%
1995
1996
Ending subs (millions)
Net Adds (millions)
% Change y/y
Ending Penetration
Incremental Penetration
1997
1995
33.8
9.7
40%
12.8%
3.5%
1998
1996
44.0
10.3
30%
16.4%
3.7%
1997
55.3
11.3
26%
20.4%
4.0%
1999
1998
69.2
13.9
25%
25.2%
4.8%
2000
1999
86.0
16.8
24%
31.0%
5.8%
2001E
2002E
2003E
2000
109.5
23.4
27%
38.9%
8.0%
2001E
129.9
20.4
19%
45.7%
6.8%
2002E
149.8
20.0
15%
52.2%
6.5%
2003E
167.3
17.4
12%
57.7%
5.5%
Sources: CTIA, Goldman Sachs Research estimates 1/11/02
7
Rapidly Declining Voice ARPU
ARPS (US$/month)
100
75
50
25
0
1997
1998
1999
North America
CEE
2000
2001
2002
Latin America
Asia Pacific
2003
2004
2005
2006
Western Europe
Africa/Middle East
Source: Pyramid Research
Rapid decline of voice ARPU is driven by growth of low-usage prepaid
segment. Only way to generate additional revenue is through data services
8
Consumer vs Enterprise Customer
Enterprise
Consumer



Applications like web
browsing, gaming,
music download,
location-based
services, micropayment, mobile
ticketing
Performance is key
Price sensitive




Applications like email, calender,
powerpoint
presentation,
netmeeting, voucher,
vendor payment
Security is key
Performance is also
important
Willing to pay more
9
Outline
 Introduction
 Challenges in
o Consumer segment
 Data Performance
o Enterprise segment
 Security
 Conclusion
10
Challenges in
Consumer Segment
11
End-to-End Architecture for CDMA2000 Network
Servers
Wireless access
PDSN
Internet
Packet Core
PCF
MSC/ RNC
BTS
PDSN: Packet Data Serving Node
PPP Connection
End-to-End TCP/IP Connection
-2001 : Mostly Circuit Switched Wireless Networks based at 9.6 Kbps
2001-2002 : 2.5G Networks (using packet switching technology) 13-20 Kbps
2002-2004? : 3G Networks (1X RTT): 40-100 Kbps; EV-DO: 600 Kbps
 Q: How can the carriers improve throughput and response time?
12
Wireless Data Accelerators

Speed up user’s wireless data experience


Decrease amount of data sent through Wireless interface


“Wireline Experience over Wireless”
Boosts Network Capacity
Different levels of optimizations:
Application Optimizations
(e.g. compression)
Session Optimizations
(e.g. DNS Boosting)
TCP Optimizations
(e.g. Delay-jitter algorithm, ACK regulator)
MAC optimizations
(e.g. Qos, FEC)
13
Wireless Data Accelerators
Application Optimizations
(e.g. compression)
Session Optimizations
(e.g. DNS response rewriting, url rewriting)
TCP Optimizations
(e.g. Delay-jitter algorithm, ACK regulator)
MAC optimizations
(e.g. Qos, FEC)
14
Application Optimizations

Web Optimizations
 Lossy compression of images





Recolor images (gifs and jpegs)
Eliminate animated gifs
Lossless compression of text/html
Removal and compression of HTTP headers
E-mail Optimizations (targeted for PDAs/Cellphones)
 Remove attachments
 Provide URLs pointing to attachments
 Remove extraneous white-space
 Remove vowels, provide e-mail summary, compress words
15
Data Compression Factors
Most important Content Types
Compression factor
average / max
HTML
x 3.84 / x 8.8
CSS
x 4.9 / x 7.5
Java Scripts
x 2.73 / x 6.48
Gif
x 2.44 / x 22.83
JPEG
x 2 / x 6.5
PAGE
x 3.38 / x 4.1
•75 KB Web page at $10/Mbit
• No data accelerator: $6
• Data accelerator: $1.7
16
Latency Reduction
Speedup Distribution
100.00%
80.00%
Average / Max
60.00%
x 2.74 / x 5.67
CDF
Speedup
40.00%
20.00%
.00%
0
1
2
3
4
5
6
7
8
Speedup
•100 KB Web page through 1xRTT (application-level throughput=40 Kbps)
•No data accelerator: 20 sec
•Data accelerator: 5 sec
17
Image Quality
4 seconds at 150Kbps
original JPEG 50k bytes
4 seconds at 30kbps
optimized JPEG 10k bytes
“Wireline over Wireless”
18
Wireless Data Accelerators
Application Optimizations
(e.g. compression)
Session Optimizations
(e.g. DNS response rewriting, url rewriting)
TCP Optimizations
(e.g. Delay-jitter algorithm, ACK regulator)
MAC optimizations
(e.g. Qos, FEC)
19
Session Optimizations (Problem overview)
• Wireless links have very large Round Trip Times (RTTs)
due to retransmission at the link layer: 400 msec- 1 sec
• Internet applications were not built with such large and
variable delays in mind:
• shows up in session layer (DNS Lookup)
• User experienced throughput is much lower than expected
» Maximum Airlink Data Rate (physical layer): 153.6 kbps
» Maximum TCP Throughput (with protocol overhead): 128 kbps
» FTP throughput: 100-120 Kbps
» HTTP throughput: 50-70 Kbps
20
Session Optimizations (HTTP Problem)

Popular Pages usually contain several embedded objects that are
hosted in different domain names
 e.g. weather.cnn.com, finance.cnn.com, a796.g.akamai.net
health.cnn.com
http://cnn.com/index.html
weather.cnn.com
image
Internet
finance.cnn.com
sports.cnn.com
a796.g.akamai.net



MS performs new DNS query for each domain name
 1-3 seconds delay
 DNS response TTLs for popular Web sites tend to be small leading
to frequent DNS requests
MS opens a new TCP connection for each domain name
TCP setup and DNS queries can account for significant overhead 21
Session Optimizations

Goals:




Avoid DNS lookups through the Wireless link
Avoid multiple TCP connections through the Wireless link
Ensure that Web traffic behaves like a long-lived FTP flow
Obvious Solutions:

Explicit Proxy Configuration


Configure a proxy on the browser
Bundling Content

Bundle all content into a single file before it is sent to the client.
22
Explicit Proxy

Goals: browser must fetch all objects from a single proxy



Avoids DNS look-ups
Avoids multiple TCP connections over the wireless link
Limitations:

Difficult to configure/maintain client’s browser
>90% of all proxy deployments are in transparent mode
(browser doesn’t need to be explicitly configured to use the proxy)

23
Bundling Content

Goals: combine all objects into a single downloadable file


only one DNS request and one TCP connection over the wireless link.
Limitations:

Traditional proxies are not capable of bundling content


Needs new proxy .
Traditional browsers (Netscape/Internet Explorer) are not capable of
breaking a bundled page into individual components

Needs new browser
24
Our Solution: Session-Layer Optimization


Goals:

browser must fetch all objects from a single proxy

Avoid DNS lookups and reuse TCP connections with proxy

No change in standard browser
Two possible complementary implementations


URL rewriting
DNS response rewriting
25
Url Rewriting
Rewrite urls to point to a proxy
Avoids DNS look-up
Reuses a single TCP connection
Rewritten
Caching
Proxy
10.0.0.12
<img src = http://i.cnn.net/images/plane.jpg>
<img src = http:// www.foo.com/views/latest.gif>
<img src = http:// images.yahoo.com/news/world.jpg>
<img src = http:// www.news.com/news/rpundup.gif>
(4) Original
(5)
(6)
(1)
URL
Rewriting
Proxy
(3)
www.foo.com
(2)
i.cnn.net
<img src = http:// 10.0.0.12/i.cnn.net/images/plane.jpg>
<img src = http:// 10.0.0.12/www.foo.com/views/latest.gif>
Images.yahoo.com
<img src = http:// 10.0.0.12/images.yahoo.com/news/world.jpg>
<img src = http:// 10.0.0.12/www.news.com/news/roundup.gif>
www.news.com
26
DNS Response Rewriting
Caching
Proxy
10.0.0.12
(12)
(11)
(10)
IP: 10.0.0.12
-----------------GET /index.html HTTP/1.1
Host: www.foo.com
(9)
(7)
(6)
(5)
(8)
(1)
Name: www.foo.com
IP: ???
(4)
Name: www.foo.com
IP: 10.0.0.12
TTL: 1 day
IP: 193.123.25.10
TTL: 10 sec
www.foo.com
193.123.25.10
Name: www.foo.com
IP: ???
DNS
Rewriting
Proxy
(2)
DNS Server
(3)
Name: www.foo.com
IP: 193.123.25.10
TTL: 10 sec
27
Comparison with other Techniques
Explicit
Proxy
URL
Rewriting
DNS Response
Rewriting
ContentBundling
Free from
Browser
Configuration
No
Yes
Yes
No
No Client-Side
Component
required
Yes
Yes
Yes
No
Works with
traditional
caching proxies
Yes
Yes (with very
minimal
change)
Yes
No
28
Experimental Set-up
Apache Web Server
(Virtual Hosting)
www.cnn.com
www.yahoo.com
www.britannica.com
Top 100 URLs
DNS Server
Squid Caching Proxy
(Transparent Mode)
Transparent
redirection
URL rewriting
DNS rewriting
proxy
WiDSE
(1xRTT)
Client Mobile Node
(Mozilla Browser)
29
Performance Improvement Summary
Without Session Layer
optimizations
HTTP Proxy
Image 1
DNS 1
OS1
OS2
TCP 1
TCP 2
Image 2
DNS Server
DNS 2
HTTP Proxy
With Session Layer
optimizations
30 – 50 % decrease in response time
50 – 100 % increase in throughput
TCP
Image 1
OS1
OS2
Image 2
DNS Server
30
Experimental Details

Three Web pages fully replicated locally





www.cnn.com: 143 KB, 6 domains, 58 objects
www.yahoo.com: 74 KB, 3 domains, 16 objects
www.britannica.com: 167 KB, 14 domains, 32 objects
Instrumented Netscape to automatically download Web pages
Average results over 20 samples
31
Results: TCP Connections and DNS Requests
Top 100 URLs
Number of TCP Conn (or)
DNS Requests
1200
1000
TCP Connections
800
DNS Requests
600
400
200
0
DNSRW
URLRW
NULL
Session Level Optim ization Technique
Number of TCP connections and DNS queries is much smaller with session-level
optimizations: TCP connections reduced up to 500%; DNS requests reduced up to 50%
32
Results: User Perceived Response Time (average cell)
Response Time. Average Cell
(RTT = 400 msec)
Response Time (sec)
45
40
35
30
30%
34%
33%
32%
CNN
25
Yahoo
20
Britannica
15
10
26%
26%
5
0
DNSRW
URLRW
NULL
Session Level Optimization Technique
Session-level optimizations provide an improvement of 25%-35%
DNS Response Re-writting and Url Re-writing provide similar benefits
The higher the number the objects/domains, the higher the improvement
33
Results: User Perceived Response Time (congested cell)
Response Time. Congested Cell
(RTT = 600 msec)
Response Time (sec)
70
60
50
40
55%
49%
50%
CNN
53%
Yahoo
Britannica
30
20
48%
55%
DNSRW
URLRW
10
0
NULL
Session Level Optimization Technique
Session-level optimizations provide an improvement of up to 55%
DNS Response Re-writing and Url Re-writing provide similar benefits
34
Results: HTTP Throughout (average cell)
Throughput. Average Cell
(FTP Throughput = 78 Kbps)
80
Throughput (Kbps)
70
60
51%
36%
50%
44%
36%
48%
CNN
50
Yahoo
40
Britannica
30
20
10
0
DNSRW
URLRW
NULL
Session Level Optimization Technique
35
Results: HTTP Throughout (congested cell)
Throughput. Congested Cell
(FTP Throughput = 56 Kbps)
Throughput (Kbps)
60
50
124%
126%
93%
98%
101%
117%
40
CNN
Yahoo
30
Britannica
20
10
0
DNSRW
URLRW
NULL
Session Level Optimization Technique
Session-level optimizations provide more improvement when network
conditions worsen (95%-125% improvement in throughput)
36
Wireless Data Accelerators
Application Optimizations
(e.g. compression)
Session Optimizations
(e.g. DNS response rewriting, url rewriting)
TCP Optimizations
(e.g. Delay-jitter algorithm, ACK regulator )
MAC optimizations
(e.g. Qos, FEC)
37
TCP and Wireless Networks




TCP was targeted for terrestrial links with

Few corruption losses (most losses are due to congestion)

Low Round Trip Time (RTT); Low Variability/Jitter
In Wireless

Most of losses are corruption losses

Round Trip Times are quite high (400-1000 msec); High Variability/Jitter
Link layer losses are hidden from the transport layers
 Retransmission and Forward Error Correction

As a result TCP sees very few losses
Still, TCP has problems:



Link level reliability removes corruption losses but
increases Round Trip Times from 200-400 msec to 2-3 sec leading to loss of
throughput
Current TCP timeout algorithms do not work properly under links with high
delay variability

Unnecessary retransmissions leading to loss of throughput
TCP is quite bursty

Increases probability of losing packets leading to loss of throughputs
38
3G1X RTT Link Delay Variability
• Experiment Setup:
•3G1X RTT system and mobile device with 3G1X modem
•144 kbps downlink in infinite burst mode and 8 kbps uplink
• Results:
•No loss observed in ping packets
•75% of ping latency values are less than 200ms and
more than 20% of ping latency varies between 200ms and 500ms
39
Simulation: Variable Delay
• Simulation set-up:
• Constant rate of 200kb/s, delay variation is exponentially distributed
• Simulate only congestion loss
• Larger variation causes larger degradation in TCP throughput
• Increasing buffer size increases throughput at the expense of larger RTT 40
TCP Modeling: Window Evolution
TCP with no variation
TCP with delay variation
Because of Delay Variations:
Buffer overflow occurs early leading to Lower average TCP window size
 Multiple drops results in larger window back-off and time-outs leading to
Low Average Throughput
41
Solution (Ramjee/Chan – Mobicom 2002)

Ack Regulator

Tries to keep buffer size large enough to avoid packet
loss and small enough to reduce delay


When TCP congestion window is “small”, have large enough buffer to
avoid buffer overflow (packet loss)
When TCP congestion window is “large”, have small enough buffer to
allow one packet loss but avoid multiple packet loss
42
Simulation Result: Window Evolution
Reno
Reno w/ AR
Ack Regulation (AR) changes the window evolution
behavior to be closer to the classic saw-tooth, and
• reduces the number of multiple packet loss
• maintains a higher average maximum window size
• reduces the number of loss events
43
Multiple TCP Flows over 3G1X EV-DO (HDR)
4 TCP Flows
8 TCP Flows
• With multiple TCP flows, improvement over Reno and Sack is significant
• Performance improvement is more significant when buffer size is small
• Throughput performance of AR is fairly robust w.r.t. to buffer size
44
Summary & Open issues in TCP Ack Regulation

Results




Improves performance of TCP Reno and Sack up to 40%
Delivers robust performance across different buffer size
Reduces round trip time for the same bandwidth achieved
Open Issues


Ack Regulator for Short flows
Problem with end-to-end IPSEC
45
Wireless Data Accelerators
Application Optimizations
(e.g. compression)
Session Optimizations
(e.g. DNS response rewriting, url rewriting)
TCP Optimizations
(e.g. Delay-jitter algorithm, ACK regulator )
MAC optimizations
(e.g. Qos, FEC)
46
TCP Timeout Problem

TCP Timeout Problem in 3G/1X Systems

Round-Trip Time (RTT) can increase abruptly (so-called Delay
Spikes) due to RLP retransmissions, link condition changes,
scheduling priorities, etc.

Delay Spikes can cause TCP Timeout: shuts down TCP Window
and drastically reduces throughput
47
RTT / RTO in a 3G Network
3000
RTT
RTO
2500
RTO = Retransmission
Time Out
RTT = Round Trip Time
RTT / RTO (msec)
Timeouts
ms
2000
1500
1000
500
0
0
10
20
30
40
50
60
70
80
90
100
Packet Index
RTO = Estimated RTT + 4 * RTT Deviation
Delay spikes lead to Timeouts; cutting TCP window to 1
48
How to deal with delay spikes? Naïve Solution
Inject delay every
10 RLP frames
20
20
10
20
20
10
MT
TE
Rm
interface
TCP
20
IP
PPP
20
10
RLP 2 20
…
RLP
Session
BTS
BSC
PCF
GRE
Session
PDSN
GRE
Session
I
N
T
E
R
N
E
T
RTO = Estimated RTT + 4 * RTT Dev
Injecting artificial delay increases RTT Dev
This increases RTO and thus
Avoids TCP timeouts
Prevents loss of TCP throughput
49
Drawbacks of the Naïve Solution

Not robust as effectiveness depends on applications,
data rate, traffic direction, and number of active TCP
connections per user

Choice of control parameters (e.g., delay 180 msec
once every 10 RLP frames) may be inappropriate
50
An Enhanced Delay-Jitter Algorithm (Leung/Klein)
•
Key Observation:
– For typical applications, not much fragmentation from TCP/IP to PPP
– Most of fragmentation occurs between PPP and RLP
TCP Segment ~ PPP Frame
•
Enhanced Solution:
Insert extra delay at PPP Layer on PCF
instead of inserting delay at RLP Layer on BSC
(More effectively deals with TCP at PPP level)
– PCF identifies PPP Packet Delimiter
– Count each PPP packet as a TCP packet
•
Benefits:
– More effectively avoids TCP Timeout to maintain throughput
– Increases robustness and wider applicability
51
Enhanced Delay Jitter Algorithm
Inject delay every
“n” PPP frames
20
20
10
10
TE
Rm
interface
TCP
20
IP
PPP
20
10
RLP 2 20
RLP
Session
BTS
20
10
BSC
MT
20
PCF
GRE
Session
PDSN
GRE
Session
I
N
T
E
R
N
E
T
RTO = Estimated RTT + 4 * RTT Dev
Injecting artificial delay increases RTT Dev
This increases RTO and thus
Avoids TCP timeouts
Prevents loss of TCP throughput
52
Enhanced Delay Jitter Algorithm (more)

Different versions:



Fixed time – fixed delay (FTFD): inject delay according to schedule,
i.e. inject delay D0 every N packets.
Random time – fixed delay (RTFD): inject fixed delay D0 to every
packet with probability p=1/N.
Random time – random delay (RTRD): inject delay to every packet
with certain probability p=1/N; injected delay is chosen according
to some pdf with mean D0 (in simulations, chose exponential
distribution).
53
Effect of Enhanced Delay Jitter (EDJ) Algo on TCP Timeouts
D0 = 100 msec
300
FTFD
RTFD
RTRD
Total Number of Timeouts
250
Injecting 100ms
delay does not
reduce # timeouts
200
150
100
Timeouts
50
Without
EDJ algo0
0
10
1
10
10
2
Fixed or Average Jitter Period
500
D0=200 m se c
FT FD
RT FD
RT RD
450
Total Number of Timeouts
400
350
Injecting 200ms
delay reduces #
timeouts
300
250
Timeouts
200
Without
150
EDJ algo
100
50
0 0
10
1
10
Fixe d or Av e rage Jitte r Period
10
2
54
Effect of Enhanced Delay Jitter Algorithm on TCP Timeouts
D0=300 msec
600
FTFD
RTFD
RTRD
Total Number of Timeouts
500
Injecting 300ms
delay every N=2/3/4
samples reduces #
timeouts
400
300
200
100
Timeouts
Without010
EDJ algo
0
1000
1
10
Fixed or Average Jitter Period
2
D0=400 msec
FTFD
RTFD
RTRD
900
800
Total Number of Timeouts
10
Injecting 400ms
delay every N=2/3/4
samples reduces #
timeouts
700
600
500
Timeouts
400
Without
300
EDJ algo
Bad choice of
Parameters can
Increase the # of
timeouts
200
100
0 0
10
Bad choice of
Parameters can
Increase the # of
timeouts
1
10
Fixed or Average Jitter Period
10
2
55
RTT/RTO with and without Enhanced Delay Jitter Algorithm
3000
RTT
RTO
2500
RTT / RTO (msec)
Timeouts
2000
Without
Enhanced Delay
Jitter Algorithm:
1500
RTO is ~700ms
1000
500
0
0
10
20
30
40
50
60
70
80
90
2 timeouts in the
example
100
Packet Index
3500
RTT
RTO
3000
Timeout
RTT / RTO (msec)
2500
With Enhanced
Delay Jitter
Algorithm:
2000
RTO is ~1200ms
1500
1000
1 timeout in the
example
500
0
0
10
20
30
40
50
Packet Index
60
70
80
90
100
56
Summary of Enhanced Delay Jitter Algorithm




With appropriate parameters, proposed methodology does reduce
number of timeout occurrences.
Random Time – Random Delay method performs quite poorly: too
much randomness introduced in the RTT. Degree of randomness in
delay injection has to be properly controlled.
Fixed Time – Fixed Delay gives optimal performance in terms of
reducing the number of timeout occurrences.
Need to assess impact on TCP throughput performance
(conflicting requirements):
 Increase in mean RTT  decreases throughput.
 Decrease in timeout occurrences  increases throughput
 Optimal choice of parameters (n, D0, p) needs to be worked out
57
Summary of Performance Enhancement Opportunities
Layer
Application
+
Session
Transport
Enhancement Opportunity
Sample applications
Speedup
Context sensitive image compression
and/or transcoding
Web, PowerPoint, Word
processor
Text compression
Web, Word processor
Up to
300400%
Application header removal and/or
compression
Web, Email
Proxy for cookies
Web
DNS lookup optimization
Web
TCP Performance Enhancements such as
Ack Regulator, Snoop, I-TCP, M-TCP
Web, Email, File Transfer
TCP/IP Header compression
Web, Email, File Transfer
Internet Offload, Service differentiation
Multiple classes of service
20-50%
* Source: Inktomi Corporation
58
Outline
 Introduction
 Challenges in
o Consumer segment
 Data Performance
o Enterprise segment
 Security
 Conclusion
59
Challenges in
Enterprise Segment
60
Business Services are projected to grow strongly
North America 3G Operator Services Revenue
25000
20000
15000
10000
5000
0
2003
2004
2005
Simple voice --- --Busines MMS --- --Mobile Intranet/Extranet Access --- ---
2006
2007
Rich voice --- --Mobile Internet Access --- --Customized Infotainment --- ---
2008
2009
2010
Location Based Services --- --Consumer MMS --- ---
 Business oriented high-speed data services for enterprise
intranet/extranet access will drive demand for 3G and surpass voice
 Carriers will need to provide Virtual Private Network (VPN) services
UMTS Forum: 2001
61
Two choices for Virtual Private Network (VPN)
End-to-end
IPSec tunnel
INTERNET
IP Service Switch/
PDSN
Firewall
VPN
Gateway
Split Ipsec
tunnels
Split Ipsec
tunnels
End-to-end Tunnel
Split Tunnel
End-to-End IPSec Tunnel-based VPN
Network-based Split IPSec VPN
Carrier provides simple transport
Carrier provides value-added
services like aggregation
Carrier charges flat rate
Carrier charges premium for
value-added services
62


End-to-End IPSec-based VPN
Enterprise
VPN Gateway
Subscriber
Access Terminal
PDSN
AT
Application
Data
encrypt
Application
Header
Application
Data
Application
Data
Application
Data
Application
Header
Application
Header
Application
Header
TCP
TCP
TCP
TCP
TCP
IP
IP
IP
IP
IP
IPSec
IPSec
IPSec
IP
IP
IP
Encryption at Client
Intermediate Nodes
See only encrypted headers/data
Application
Data
decrypt
Application
Header
Decryption at VPN Gateway
Today’s common solution offers end-to-end security, but does not allow
network-based enhancements/services that require access to header
information
Carriers become simple transport providers and can only charge at flat rate
63
Network-based Split IPSec VPN
Enterprise
VPN Gateway
Subscriber
Access Terminal
PDSN
AT
decrypt
encrypt
encrypt
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
TCP
TCP
TCP
TCP
TCP
TCP
TCP
IP
IP
IP
IP
IP
IP
IP
IPSec
IPSec
IPSec
IPSec
IP
IP
IP
IP
Encryption at Client
decrypt
Intermediate Nodes
Header/Data exposed
Decryption at VPN Gateway

Enterprise data is exposed within carrier network
All network-based enhancements are possible (Application/Session/TCP optimizations)

Carriers can charge premium for value-added services

64
Dilemma for a Wireless Carrier
Wireless access
PDSN
Internet
VPN
Gateway
Packet Core
Corporate
WAN
PCF
MSC/ RNC
BTS
Encrypted IPSec tunnel forming a Virtual Private Network
 For enterprise customers, Security is key
 Faster response time and higher throughput are also important
 With end-to-end IPSec, carrier cannot add value!
 Challenge: Can we preserve security and at the same time
provide value-added services and performance improvement?
65
Adaptive VPN
User
Carrier Network Enterprise
• End-to-end security for all applications and users
• Network cannot enable any new service
User
Carrier Network Enterprise
• User data come in clear inside Carrier’s IPSS
• Network enables new services for all users
End-to-end VPN
Network-based VPN
Adaptive VPN
Flexibility in
providing
different VPN
services to
different
application/user
User
Carrier Network Enterprise
• End-to-end security for some applications/users
• Network enabled new services for some applications/users
Value-added
services based
on IP, TCP and
application
level headers
and application
data
66
User-based and Application-based
Adaptive VPN
End-to-End VPN
Network-based VPN
Application
Example:
Officer
Executive
Staff
E-mail
Web
other
Officer@Company
AAA
Firewall
Executive@Company
VPN
Gateway
IP Service Switch
Staff@Company
End-to-end Tunnel
Split Tunnel
67
Policy Download with Adaptive VPN
NAI
Selection criteria
VPN End-point
Officer
@company
Dest IP: All
TCP port: All
Executive
@company
Dest IP: 192.168.5.0/24
TCP port: 25, 80
135.180.144.254
Dest IP: All
TCP Port: All
135.180.244.150
Staff
@company
Dest IP: All
TCP Port: All
135.180.144.254
AAA/LSMS
135.180.244.150
Firewall
135.180.244.150
135.180.144.254
VPN
Gate
way
Executive
@company
192.168.5.0/24
IP Service Switch
End-to-end Tunnel
Split Tunnel
Web server
(Port 80)
Mail
Server
(Port 25)
68
Adaptive VPN Demo
Enterprise Network
Enterprise VPN Gateway
LVF Brick
Tunnel A
Local Presence IP
192.168.5.10
Hosts behind tunnel
192.168.5.0/24
192.168.5.0/24
135.180.144.254
Tunnel A
Physical IP
130.160.140.17
Network VPN
Gateway
Client
129.180.244.15
Tunnel B
Tunnel C
Hosts behind tunnel
192.168.3.0/24
192.168.3.0/24
Local Presence IP
192.168.1.10
Hosts behind tunnel
192.168.1.0/24
192.168.3.0/24
192.168.1.0/24
69
Multi-Layer IPSec (ML-IPS)
Enterprise
VPN Gateway
Subscriber
Access Terminal
PDSN
AT
decrypt
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Data
decrypt
Applic.
Data
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
Applic.
Header
TCP
TCP
TCP
TCP
TCP
TCP
TCP
IP
IP
IP
IP
IP
IP
IP
IPSec
IPSec
IPSec
IPSec
IPSec
IP
IP
IP
IP
IP
Encryption at Client


encrypt
encrypt
Applic.
Data
Intermediate Nodes
Headers exposed
Enterprise Data protected
Decryption at VPN Gateway
Enterprise data is encrypted end-to-end (Protocol headers exposed to carrier)
Many network-based enhancements/services are possible
70
Multi-Layer IPSec (ML-IPS): Evolution of IPSec
Example outgoing packets
Data
Applic. Hdr.
Data
Applic. Hdr.
TCP
IP
Rules
Engine
ML-IPS
Client or VPN GW
TCP
IP
video
RTP hdr.
UDP
IP
Expanded
Rules Engine
End2End Key
Encryption
Packet
Splitting
ftp
header.
TCP
IP
web
HTTP hdr.
TCP
IP
Carrier Key
Encryption
Two Key
Encryption
video
RTP hdr.
UDP
IP
email
header
TCP
IP
Capability
added w/
ML-IPS
ML-IPS
supports
Split & E2E
IPSec options
Per packet options
“trusted” to carrier
Secure end-to-end
Benefits

Enterprise decides security policy for what content is trusted to carrier
–

Not only application and user control, but also “section of packet” control
Many network-based enhancements/services are possible while still
preserving end-to-end security of enterprise content
71
Summary of Security Options for VPN
Network-based Services
Today
Adaptive-VPN
End-to-End IPSec
ML-IPS
Application Compression
Internet Offload/Caching
URL Blocking/Filtering
Stateful Firewall
Denial of Service prevention
TCP-based enhancements/scheduling
Scheduling based on Application/QoS
Header compression
Possible for all traffic, with end-to-end security preserved
Possible for some traffic, end-to-end security not preserved
Not possible
72
An example of a futuristic application
73
Converged voice/data/streaming video service across
CDMA/UMTS and Landline connection
Let’s see if
We need to
thebuy
kidssome
are
How
about
this?
flowers for the
party.
okay.
Doshow
you like
Let me
you the
a
vase?
few bouquets.
This is perfect!
I like the roses.
Can I have them
In a different vase?
CDMA
Call
Next Done
Party 1
Dad
1-800-Flowers.
How can I help
you?
Call
Next Done
Data Connection
Voice Connection
Video Connection
UMTS
Party 2
Mom
Landline
Party 3
Day Care
74
Another Converged Service Example: Expert on Call
Streaming Media, Real-time voice, Best Effort Data Convergence
Something doesn’t
seem right. Am I testing
the right circuit?
This is the one I’m
working on.
No, that’s not the correct
one. Scan to the left,
I’ll tell you to stop when
you get to the right spot.
Expert technician at field site #2.
Less experienced technician at field site #1.
75
Outline
 Introduction
 Challenges in
o Consumer segment
 Data Performance
o Enterprise segment
 Security
 Conclusion
76
Conclusion
 Challenges for 3G Wireless Data Services (being explored)
 Improving Data Performance
 Preserving Security while providing value-added services
 Enable QoS-sensitive applications like Gaming,VOIP,Pushto-Talk
 Challenges for 3G Wireless Data Services (not yet explored)
 Multicast
 Secure group communication (chat)
 Quality of Service issues
 Opportunities abound in solving practical problems and
enabling carriers to provide high-speed data services and
novel multi-media applications while reducing capex and opex
for a carrier
77
BACK UP
78
Browser Issues

Browser does not reuse persistent connections to servers with different
domain names and identical IP address



Browser keeps opening new connections, even if max_connect is
reached



Browser’s bug (breaks persistent connections for Virtual Hosts)
Impacts DNS rewriting, but not URL rewriting
Browser does this while it finds no idle connections
Opens almost as many connections as objects
Simple browser modifications/configuration fixes these issues

Should be incorporated in Wireless browsers
79
More on Session Optimization

Sessions should be kept alive even under mobility
scenarios

TCP for temporal disconnections


User goes through tunnel, server connection is still kept alive
Sessions should be kept alive even after a certain idle
time (e.g. think time)

TCP for frequent channel releases

Gold users do not need to go through a Wireless channel adquisition
each time they request a new page
80
Temporal Disconnection
Problem:

With Temporal Disconnections, TCP ACKs do not flow to the server
from the mobile client – TCP at the server starts backing off and
eventually the server resets the connection.
Solution: TCP Proxy



TCP proxy keeps state of the TCP connections from the mobile client
to the server.
When disconnection is noticed (no packets from the mobile), TCP
packets with a window size of zero are generated by the TCP proxy
and sent to the server - this effectively freezes the TCP end-point at
the server.
Once connection is established with the mobile, the TCP window size
is left as is on the packets from client to server thereby allowing the
server to start sending packets.
81
Frequent Channel Release
Problem:


Mobile nodes release Wireless channels after a certain quiet period if no
data packets are received. This timeout period is small (3 – 4 sec.) and it
takes 2 to 3 sec. to re-acquire a channel.
During a normal browsing operation there are frequent periods of
inactivity when data packets do not flow to the mobile (e.g. idle RTTs in
between image requests) - if Wireless channel is frequently released in
the middle of a TCP session, end-user experience is significantly
degraded.
Solution: TCP Proxy


During quiet periods, TCP ping packets are generated by the TCP proxy
and sent to the mobile.
Mobile sees continuous data flow on the channel it is holding and so it
does not release the channel - once data session is resumed, no more
keep-alive packets are generated.
82
Compromise Solution: Adaptive VPN
End-to-end
tunnel only
Firewall
Both end-to-end
and split tunnels
Split tunnel
only
VPN
Gateway
IP Service Switch
End-to-end Tunnel
Split Tunnel
Mobile Users
3G Carrier/Public Network
Enterprise
• Decision on tunnel is based on
user and/or application requirement
• Application to tunnel mapping is
done dynamically
• Decision on tunnel is based on user
id and/or enterprise requirement
• VPN tunnel mapping is done at
setup with help from AAA
• Terminates any
secure tunnel
• Oblivious to
different tunnels
83
Adaptive VPN:
Added flexibility to Network-based VPN
Example outgoing packets
A-VPN client
Client or VPN GW
End2End
Tunnel
Data
Applic. Hdr.
TCP
IP
Rules
Engine
Carrier
Tunnel
Expanded
Rules Engine
Tunnel
Selection
Separate
Tunnels
email
header
TCP
IP
End2End
Secure,
No enhancements
possible
web
HTTP hdr.
TCP
IP
Trusted to Carrier,
enhancements
possible
Per packet options
“trusted” to carrier
Secure end-to-end
Benefit

Enterprise decides security policy for what content is trusted to carrier
–

application and user control
No standards change, simple additional development
Limitation

Network-based enhancements/services only possible by giving up end-to-end security
84
A-VPN implementation with ML-IPSec
support is transparent to client
Terminate packets
to port 80
Forward packets
to port 25
End-toend VPN
Firewall
CPE
PDSN/SG
decrypt
encrypt
Applic.
Data
Applic.
Data
Applic.
Data
Applic.
Header
Applic.
Header
Applic.
Header
TCP
TCP
TCP
IP
IP
IP
IPSec
IPSec
IPSec
IP
IP
IP
Networkbased VPN
 TCP headers are exposed with IP SuperSec
 Because of this, the PDSN can identify
the application
85
A-VPN client implementation
End-toend VPN
Firewall
Applic.
Data
CPE
PDSN/SG
Applic.
Header
TCP
IP
Packets to
TCP port 25
(E-mail)
Packets to
TCP port 80
(Web)
IPSec
 Applications identified using TCP port number
 Client needs to be modified
IP
Tunnel to
PDSN
Networkbased VPN
Tunnel to
CPE
86
Adaptive VPN Implementation



Lucent VPN security products modified for Adaptive VPN
Modified IPSec client
Modified LSMS (Lucent Security Management System)
LSMS
IPSec
client
Firewall
VPN
Gate
way
Executive
@company
IP Service Switch
End-to-end Tunnel
Split Tunnel
87
Routing Table at the client with Adaptive VPN
One tunnel


Two tunnels
Without Adaptive VPN, routes to reach the subnets behind the tunnel added that specify
the Local Presence IP address as the gateway
With Adaptive VPN, subnets behind the tunnel can be reached either through the Endto-end tunnel or the Network tunnel. Routes are added to the routing table with the
appropriate Local Presence IP address as the gateway
88
3GPP2 IMS QoS Architecture for Simple IP
Home Access
Provider network
SS7 Network
MSC
HLR
Broker network
AAA
SO QoS
Subscription
Authorization
Home IP network QoS Resource
AAA
• Let diffserv CP
marking go through
• Remark packet
diffserv CP if needed
SDP 
Service Option (SO)
Mapping + BLO
RAN
AAA
SIP Header
Compression
Policy
DB
CSCF
R
SDP QoS
Subscription
Authorization
Diffserv
aware
Diffserv
marking
Subscription
IP Network
External IP Network
Diffserv Aware
PDSN
MS
QoS
Interworking
Diffserv CP
PDF/CQM
SIP/RTP Header
Compression
SIP/RTP
SIP/RTP
UDP
UDP
UDP
IP
IP
IP
PPP
PPP
R
R
R e m o te H o s t
SIP/RTP
LAC
LAC
MAC
MAC
Airlink
Airlink
Link Layer
R-P
R-P
PL
PL
PL
PDF=Policy Decision Function
CQM = Core QoS Manager
89
CDMA 2000 Network Architecture
BSC
MT
TE
TCP
GRE
Session
20
IP
I
N
T
E
R
N
E
T
BTS
20
PPP
PDSN
GRE
Session
RLP
Session
Rm
interface
PCF
10
RLP 2 20
Air
Interface
Rm
Abis
A8/A9
A10/A11
TCP
UDP
TCP
UDP
IP
IP
TE
IP
WAN
WAN
PPP
PPP
Low-Level
Interface
IP
Low-Level
Interface
RLP
IS2000
MT
IS2000
PP
BTS
GRE
GRE
RLP
IP
IP
GRE
IP
PP
T1
T1
T1
BSC
PCF
WAN
PDSN
router
TE
90
RTT Histogram with Delay Jitter Algorithm
Histogram of RTT
600
Fixed or Average Delay: D0=300 msec
Fixed or Average Jitter Period: N=2
Number of Occurrences
500
no delay jitter
FTFD
RTFD
RTRD
400
300
200
100
0
400
500
600
700
800
900
1000
msec
91
Url Rewriting

Steps




Browser first fetches the top-level page from origin server
The page is parsed by an intercepting URL rewriting
proxy
All embedded objects hosted in a different Web server
than the top-level page are prefixed with the IP address of
a caching proxy (say, 10.0.0.12)
 For example
http://i.cnn.net/images/plane.jpg
is changed to:
http://10.0.0.12/i.cnn.net/images/plane.jpg
The browser connects to the caching proxy to retrieve all
embedded objects over a single persistent HTTP (TCP)
connection. No DNS requests at the browser needed as
92
IP address of caching proxy is prefixed
DNS Response Rewriting

Steps





All DNS responses intercepted by a DNS rewriting proxy
DNS responses are rewritten to add the IP address of a caching
proxy to the front of the list of IP addresses returned by the DNS
server
DNS TTL response is increased
Original IP addresses that are returned by the DNS server are left
as they are to enable mobile roaming
The browser connects to the caching proxy to retrieve the
top-level page and the embedded objects.


All objects retrieved over a single persistent HTTP (TCP)
connection.
DNS requests made once and cached for an extended period
because of the increased TTL. This prevents DNS queries for a
long time and hence improves latency
93
Histogram of RTT
RTT distribution (32 bytes)
600
500
400
300
200
100
0
400
600
800
1000
1200
RTT is concentrated between 500-700ms for short pings
94
Histogram of RTT
RTT distribution (300 bytes)
1200
1000
800
600
400
200
0
800
900
1000
1100
1200
1300
1400
RTT is concentrated between 900-1000ms for large pings
95
96