/images/plane.jpg>

(3) www.foo.com

i.cnn.net

Images.yahoo.com

www.news.com

26

DNS Response Rewriting

Caching Proxy 10.0.0.12

(11) (12) (10) IP: 10.0.0.12

----------------- GET /index.html HTTP/1.1

Host: www.foo.com

(9) (6) (7) Name: www.foo.com

IP: ???

(5) (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 DNS Rewriting Proxy (8) (2) (3) Name: www.foo.com

IP: 193.123.25.10

TTL: 10 sec

www.foo.com

193.123.25.10

DNS Server 27

Comparison with other Techniques

Free from Browser Configuration No Client-Side Component required Works with traditional caching proxies Explicit Proxy No Yes Yes URL Rewriting Yes Yes Yes (with very minimal change) DNS Response Rewriting Yes Content Bundling No Yes Yes No No

28

Experimental Set-up

Apache Web Server (Virtual Hosting)

www.cnn.com

www.yahoo.com

www.britannica.com

Top 100 URLs

Squid Caching Proxy (Transparent Mode)

Transparent redirection

URL rewriting DNS rewriting proxy WiDSE (1xRTT) Client Mobile Node (Mozilla Browser) DNS Server

29

Performance Improvement Summary

Without Session Layer optimizations HTTP Proxy Image 1 DNS 1 TCP 1 TCP 2 DNS 2 DNS Server Image 2 With Session Layer optimizations

30 – 50 % decrease in response time 50 – 100 % increase in throughput

TCP HTTP Proxy Image 1 DNS Server Image 2 OS1 OS2 OS1 OS2 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

1200 1000 800 600 400 200 0 TCP Connections DNS Requests 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%

Results: User Perceived Response Time ( average cell)

Response Time. Average Cell (RTT = 400 msec)

45 40 35 30 25 20 15 10 5 0

34% 30% 26% 33% 26% 32%

DNSRW URLRW NULL

Session Level Optimization Technique

CNN Yahoo Britannica

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)

70 60 50 40 30 20 10 0

55% 49% 50% 53% 48% 55%

DNSRW URLRW NULL

Session Level Optimization Technique

CNN Yahoo Britannica

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 70 60 50 40 30 20 10 0

51% 36% 44% 50% 36% 48%

DNSRW URLRW NULL

Session Level Optimization Technique

CNN Yahoo Britannica 35

Results: HTTP Throughout ( congested cell)

Throughput. Congested Cell (FTP Throughput = 56 Kbps)

60 50 40

124% 93% 98% 126% 101% 117%

30 20 10 0 DNSRW URLRW NULL

Session Level Optimization Technique

CNN Yahoo Britannica

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 avoid buffer overflow (packet loss) to  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 2500 2000 Timeouts RTT RTO RTO = Retransmission Time Out RTT = Round Trip Time ms 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

10 20 20 TE Rm interface MT TCP IP PPP 10 20 20 RLP 2 20 Inject delay every 10 RLP frames BTS

…

RLP Session 10 20 20 BSC GRE Session PCF GRE Session PDSN 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

10 20 20 Inject delay every “n” PPP frames 10 10 20 20 TE Rm interface MT TCP IP PPP 10 20 20 RLP 2 20 RLP Session BTS BSC GRE Session PCF GRE Session PDSN 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 D 0 every N packets.



Random time – fixed delay (RTFD) : inject fixed delay D 0 packet with probability p=1/N.

to every



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 D 0 distribution).

(in simulations, chose exponential

53

Effect of Enhanced Delay Jitter (EDJ) Algo on TCP Timeouts D 0 = 100 m se c

300 250 200 150 100

Timeouts

50

Without EDJ algo

0 10 0 500 450 400 350 300 250 FT FD RT FD RT RD 10 1

Fix e d or Av e rage Jitte r Period D 0 =200 m se c

FT FD RT FD RT RD 10 2

Injecting 100ms delay does not reduce # timeouts Injecting 200ms delay reduces # timeouts

50 0 10 0 10 1

Fix e d or Av e rage Jitte r Pe riod

10 2 54

Effect of Enhanced Delay Jitter Algorithm on TCP Timeouts D 0 =300 m sec

600 FTFD RT FD RT RD 500 400 300 200

Injecting 300ms delay every N=2/3/4 samples reduces # timeouts

10 2

Bad choice of Parameters can Increase the # of timeouts

100

Timeouts Without

0 10 0

EDJ algo

1000 900 800 700 600 500

Timeouts

400

Without

300

EDJ algo

200 100 0 10 0 10 1

Fixe d or Av e rage Jitte r Period D 0 =400 m se c

FT FD RT FD RT RD 10 1

Fix e d or Av e rage Jitte r Period Injecting 400ms delay every N=2/3/4 samples reduces # timeouts

10 2

Bad choice of Parameters can Increase the # of timeouts

55

RTT/RTO with and without Enhanced Delay Jitter Algorithm 3000 2500 2000 Timeouts 1500 1000 500 0 0 10 20 30 40 50 Packet Index 60 70 3500 3000 2500 2000 1500 1000 500 0 0 Timeout 10 20 30 40 50 Packet Inde x 60 70 RTT RTO Without Enhanced Delay Jitter Algorithm:

RTO is ~700ms

80 90

2 timeouts in the

100

example

RTT RTO With Enhanced Delay Jitter Algorithm:

RTO is ~1200ms

80 90

1 timeout in the

100

example 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 reducing the number of timeout occurrences.

in terms of  Need to assess impact on TCP throughput performance (conflicting requirements):   Increase in mean RTT 

decreases

Decrease in timeout occurrences  throughput.

increases

throughput  Optimal choice of parameters ( n, D

0

, p ) needs to be worked out 57

Summary of Performance Enhancement Opportunities

Layer

Application + Session Transport

Enhancement Opportunity

Context sensitive image compression and/or transcoding Text compression

Application header removal and/or compression Proxy for cookies

DNS lookup optimization

TCP Performance Enhancements such as

Ack Regulator

, Snoop, I-TCP, M-TCP TCP/IP Header compression Internet Offload, Service differentiation Sample applications Web, PowerPoint, Word processor Web, Word processor Web, Email Web Web Web, Email, File Transfer Speedup

Up to 300 400% 20-50%

Web, Email, File Transfer Multiple classes of service * 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 charges

flat rate

Carrier provides

value-added

services like aggregation Carrier charges

premium

for value-added services 62

End-to-End IPSec-based VPN

Subscriber Access Terminal

AT

PDSN Enterprise VPN Gateway

Application Data Application Header encrypt TCP IP

Application Data Application Header TCP

IP IPSec IP

Encryption at Client Application Data Application Header TCP

IP IPSec IP

Intermediate Nodes See only encrypted headers/data Application Data Application Header TCP

IP IPSec IP decrypt Application Data Application Header TCP IP

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

encrypt

Applic.

Data Applic.

Header TCP

IP

Subscriber Access Terminal

AT

Applic.

Data Applic.

Header TCP

IP IPSec IP decrypt

Applic.

Data Applic.

Header TCP

IP IPSec IP

PDSN

encrypt

Applic.

Data Applic.

Header TCP

IP

Applic.

Data Applic.

Header TCP

IP IPSec IP

Enterprise VPN Gateway Applic.

Data Applic.

Header TCP

IP IPSec IP decrypt

Applic.

Data Applic.

Header TCP

IP

Encryption at Client 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 Packet Core

PCF MSC/ RNC BTS Encrypted IPSec tunnel forming a Virtual Private Network

VPN Gateway Corporate WAN    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 User Carrier Network Enterprise • End-to-end security for all applications and users • Network cannot enable any new service End-to-end VPN • User data come in clear inside Carrier’s IPSS • Network enables new services for all users Network-based VPN

Flexibility

providing in different VPN services to different application/user User Adaptive VPN 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

Officer End-to-End VPN Network-based VPN Executive Staff Example: Application E-mail Web other Officer@Company AAA Firewall Executive@Company VPN Gateway IP Service Switch End-to-end Tunnel Split Tunnel Staff@Company 67

Policy Download with Adaptive VPN

NAI Officer @company

Selection criteria

Dest IP: All TCP port: All

VPN End-point

135.180.144.254

Executive @company

Staff @company

Dest IP: 192.168.5.0/24 TCP port: 25, 80 Dest IP: All TCP Port: All

Dest IP: All TCP Port: All

135.180.144.254

135.180.244.150

135.180.244.150

AAA/LSMS Executive @company

135.180.244.150

Firewall

135.180.144.254

VPN Gate way IP Service Switch End-to-end Tunnel Split Tunnel Web server (Port 80) 192.168.5.0/24 Mail Server (Port 25) 68

Adaptive VPN Demo

Tunnel A

Local Presence IP 192.168.5.10

Hosts behind tunnel

192.168.5.0/24

Physical IP

130.160.140.17

Client

Tunnel B

Local Presence IP 192.168.1.10

Hosts behind tunnel

192.168.1.0/24 192.168.3.0/24 Tunnel A

Network VPN Gateway

129.180.244.15

Enterprise Network

Enterprise VPN Gateway LVF Brick

135.180.144.254

Tunnel C

Hosts behind tunnel

192.168.3.0/24 192.168.5.0/24 192.168.3.0/24 192.168.1.0/24

69

Multi-Layer IPSec (ML-IPS)

Subscriber Access Terminal

AT

PDSN Enterprise VPN Gateway

encrypt

Applic.

Data Applic.

Header TCP

IP

Applic.

Data Applic.

Header TCP

IP IPSec IP

Encryption at Client

decrypt

Applic.

Data Applic.

Header TCP Applic.

Data Applic.

Header TCP

encrypt

Applic.

Data Applic.

Header TCP

IP IPSec IP IP IPSec IP IP IPSec IP

Intermediate Nodes Headers exposed Enterprise Data protected Applic.

Data Applic.

Header TCP

IP IPSec IP decrypt

Applic.

Data Applic.

Header TCP

IP

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

Data Applic. Hdr.

TCP IP video RTP hdr.

UDP IP Rules Engine Expanded Rules Engine Data Applic. Hdr.

End2End Key Encryption Example outgoing packets ftp header.

TCP IP video RTP hdr.

UDP IP Capability added w/ ML-IPS ML-IPS Client or VPN GW TCP IP Packet Splitting Carrier Key Encryption web HTTP hdr.

TCP IP email header TCP IP ML-IPS supports Split & E2E IPSec options Two Key Encryption 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 End-to-End IPSec Adaptive-VPN 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 ML-IPS 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 This is perfect! I like the roses.

Can I have them In a different vase?

CDMA Next Done Party 1 Dad Next

1-800-Flowers. How can I help you?

Data Connection Voice Connection Video Connection Landline UMTS Party 2 Mom 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,Push to-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’s bug (breaks persistent connections for Virtual Hosts)  Impacts DNS rewriting, but not URL rewriting Browser keeps opening new connections, even if max_connect is reached   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 Both end-to-end and split tunnels Firewall VPN Gateway Split tunnel only IP Service Switch End-to-end Tunnel Split Tunnel Mobile Users • Decision on tunnel is based on user and/or application requirement • Application to tunnel mapping is done dynamically 3G Carrier/Public Network • Decision on tunnel is based on user id and/or enterprise requirement • VPN tunnel mapping is done at setup with help from AAA Enterprise • 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 Data Applic. Hdr.

TCP IP Rules Engine End2End Tunnel email header TCP IP End2End Secure, No enhancements possible Carrier Tunnel web HTTP hdr.

TCP IP Trusted to Carrier, enhancements possible Expanded Rules Engine Tunnel Selection Separate Tunnels Per packet options “trusted” to carrier Benefit

 

Enterprise decides security policy for what content is trusted to carrier

–

application and user control No standards change, simple additional development Secure end-to-end 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-to end VPN Firewall CPE PDSN/SG decrypt

Applic.

Data Applic.

Header TCP

IP IPSec IP

Applic.

Data Applic.

Header TCP

IP IPSec IP encrypt

Applic.

Data Applic.

Header TCP

IP IPSec IP Network based VPN  

TCP headers are exposed with IP SuperSec Because of this, the PDSN can identify the application

85

A-VPN client implementation

End-to end VPN Firewall CPE

Applic.

Data Applic.

Header TCP

Packets to TCP port 25 (E-mail) IP IPSec Packets to TCP port 80 (Web) IP PDSN/SG Network based VPN   Applications identified using TCP port number Client needs to be modified Tunnel to PDSN 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 End to-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

MSC Home Access Provider network HLR Broker network AAA SO QoS Subscription Authorization SDP



Service Option (SO) Mapping + BLO Diffserv marking MS SIP/RTP Header Compression RAN

• Let diffserv CP

marking go through

• Remark packet

diffserv CP if needed AAA SIP Header Compression CSCF Diffserv aware IP Network SDP QoS Subscription Authorization PDSN PDF/CQM Home IP network QoS Resource Subscription R AAA QoS Interworking Diffserv CP External IP Network Diffserv Aware R R Policy DB

R e m o te H o s t SIP/RTP SIP/RTP SIP/RTP UDP IP PPP LAC MAC Airlink LAC MAC Airlink R-P PL UDP IP PPP R-P PL UDP IP Link Layer PL

PDF=Policy Decision Function CQM = Core QoS Manager

89

CDMA 2000 Network Architecture

TE Rm interface MT RLP Session BSC GRE Session PCF GRE Session PDSN I N T E R N E T TCP IP PPP 10 20 20 BTS RLP 2 20 Rm

TCP UDP IP PPP Low-Level Interface

TE Interface

Low-Level Interface RLP IS2000

MT Air

IS2000

BTS

PP

Abis

RLP PP GRE IP T1

BSC A8/A9

GRE IP T1

PCF A10/A11

PPP IP GRE IP T1 WAN

PDSN

IP WAN

router

TCP UDP IP WAN

RTT Histogram with Delay Jitter Algorithm

Histogram of RTT 600 500 400 Fixed or Average Delay: D 0 =300 msec Fixed or Average Jitter Period: N=2 no delay jitter FTFD RTFD RTRD 300 200 100 0 400 500 600 700 msec 800 900 1000

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 IP address of caching proxy is prefixed 92

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