WirelessCom 2005 Maui, June 14, 2005

1
Virtual Web Channel Flow Aggregation for
Enhanced Ubiquitous Web Access S. Giordano,
IEEE Member, D. Lenzarini, IEEE Member, M.
Schiavoni and S. Vanini SUPSI
Switzerland, Forward Information Technologies
SA - Switzerland (silvia.giordano)_at_ supsi.ch,
(davide.lenzarini, marco.schiavoni,
salvatore.vanini) _at_ forit.ch
WirelessCom 2005 - Maui, June 14, 2005
2
The landscape
2
3
WiOptiMo (ex WiSwitch)

• Seamless handover
• It detects the access providers available and
  provides, in an automatic or semi-automatic/assist
  ed way, the best Internet connection in terms of
  bandwidth, reliability, security and cost
  effectiveness.
• It provides, in a transparent way, persistence
  and/or seamless mobility without interrupting
  active network applications or sessions.

• No networking overhead
• It does not modify any OSI protocol stack layer
  and it does not introduce any sub-layer.
• No one byte is added, no TCP/UDP or IP
  encapsulation is needed.

• It operates at layer 7 (Application layer) of the
  OSI standard
• It can support all the network access
  technologies (LAN, UMTS, Wi-Fi, GPRS, EDGE,
  CDMA).
• It is compatible with any kind of VPN client
  (Checkpoint, Cisco etc...).
• It can work in a transparent way over mobile IP
  (v4 or v6) exactly as it works over IPv4 or IPv6

• WiOptiMo architecture
• It is composed by a client part (CNAPT),
  installed on the mobile device or in any device
  of a mobile network, and a server part (SNAPT),
  installed on any Internet node (on a corporate
  front-end server, on the home PC or on a last
  mile router).
• It is mainly written in Java, it is very small
  (less than 1.7 Mbytes for the CNAPT, less than
  800 Kbytes for the SNAPT) and it requires a few
  RAM and CPU resources so it can virtually work on
  each platform providing a JVM.

WiOptiMo is patent pending (PCT/EP2004/050111,
PCT/EP2005/050599 and Taiwan - Priority date
10/2/2004)
3
4
The WiOptiMo idea
Almost every client application is able to refer
to a server application using the loopback
address
WiSwitch Seamless Handover between
Multi-Provider Networks S. Giordano, D.
Lenzarini, A. Puiatti and S. Vanini, on WONS 05
Proceedings, Jan. 2005 or on IEEE Xplore.
4
5
The WiOptiMo idea
5
6
The WiOptiMo idea
If the mobile device changes its current IP
address from IPMD1 to IPMD2, the client/server
socket breaks down. The client and server
applications detect a network problem, maybe some
data will be lost, maybe the client application
must be restarted, a new authentication is needed
and so on.
6
7
The WiOptiMo idea
The CNAPT and the SNAPT collectively acts as a
middleware, making the client application believe
to be running either on the same machine as the
server application or in a machine directly
connected to the server in a fixed way, but in
any case does not realize that it is using an
Internet connection.
7
8
The WiOptiMo idea

• During the IP transition phase
• The CNAPT stops forwarding all the outgoing IP
  packets generated by the client application.
• The SNAPT stops forwarding all the outgoing IP
  packets generated by the server and directed to
  the switching CNAPT.

WiOptiMo makes use of the TCP window mechanism to
pause the application because no acknowledge is
received. This pause is possible only until the
application timeout expires. This way the system
avoids useless buffering and in the worst case no
more than receiving window size bytes have to be
retransmitted.
8
9
The WiOptiMo idea
WiOptiMo requires two additional sockets for each
client/server socket.
The CNAPT/SNAPT socket requires an additional
application buffer on each end to store the data
sent to the network layer. This buffer is used to
retransmit the data that can be lost during an
unexpected switch so its capacity has to be equal
to the max receiving window size.
9
10
WiOptiMo Virtual Web Channel

• The problem
• HTTP does not perform well on high latency
  wireless links. This is due to the use of
  multiple TCP connections (even in the case of
  persistent connections) which imposes several DNS
  accesses and slow-start as well as RTT delay
  associated to each connection.

10
11
VWC - How does it work? (1)




11
12
VWC - How does it work? (2)

• When, on the local sockets directly connected to
  the Web browser or to the Apache proxy, the VWC
  receives one or more TCP segments, it reads up to
  64Kbytes minus 40 bytes (TCP/IP header) minus 3
  bytes (VWC header) of payload. Then it creates a
  VWC message adding the VWC header to the original
  payload and sends it through the VWC Internet
  socket.

• The VWC header is composed by three fields using
  exactly three bytes.

• Message Type CONNECT, DATA, DISCONNECT and
  SWITCH (currently not used).
• Session Index it is associated with each local
  socket opened by the browser with the local VWC
  server socket on the client side. Each session
  socket is opened on demand and when one of those
  sockets is closed, the correspondent session
  index can be used by another new socket. The
  session index is used by the VWC client/server
  demultiplexer to deliver to the proper local
  socket the inbound data.
• Payload Length each VWC message payload can
  contain at most 65536-40-3 bytes.

12
13
HTTP 1.1 vs VWC

• HTTP 1.1
• Persistent connections HTTP/1.1 can keep open
  and reuse TCP connections to transmit sequences
  of request/response messages in order to reduce
  the latency and overhead introduced by the
  management of several short-lived TCP
  connections.
• Pipelining with persistent connections a single
  TCP segment can contain multiple requests and
  responses and in this way the navigation
  performance is improved by avoiding many round
  trip delays and reducing the number of packets
  further.

• Virtual Web Channel
• Persistent connections VWC uses a sole TCP
  connection and its advantage versus the HTTP 1.1
  is obvious when the Web browser requests a web
  page that has components from different hosts or
  when it requests web pages from different hosts.
  In this case, HTTP 1.1 opens separated persistent
  connections.
• Pipelining the advantage of VWC versus the HTTP
  1.1 also in this case is obvious. VWC use of
  pipelining is native all connections are
  multiplexed in a single socket, so it can be
  applied for HTTP requests with different
  destination hosts.

13
14
WiOptiMo-VWC measurement scenario
Access Point

• Test cases
• With the original web site server
• Dir WB-OWS
• VWC WBCNAPTSNAPTWP-OWS
• WiOptiMoNoVWC WBCNAPTSNAPTWP-OWS without VWC
  modules
• With the test web site
• Dir WB-WS
• VWC WB-CNAPT-SNAPT-WP-WS
• VWCRelayOnly WB-CNAPT-SNAPT-WP-WS without
  WiOptiMo Check and Search activities
• Proxy WB-WP-WS
• WiOptiMoNoVWC WB-CNAPT-SNAPT-WP-WS without VWC
  modules

DSL Router
Internet Gateway
Internet
14
15
Overall WiOptiMo performances
WiOptiMo introduces a low computational overhead
independent from the packet size and from the
number of packets transmitted.
15
16
VWC with the original web site server (1)

• The performance gain of VWC over Dir is due
  to
• No sockets are dynamically opened on the
  Cnapt-Snapt path.
• Compression provided by the Apache Proxy.
• No DNS requests are done on the Cnapt-Snapt
  path. The DNS requests are not done using a
  wireless link, e.g. GPRS, but instead they are
  done, by the Apache proxy, on a wired network

16
17
VWC with the original web site server (2)

• The performance gain obtained by VWC vs.
  CompressedDir in GPRS is about 17 but it can
  be greater, mainly for two reasons
• the direct HTTP navigation with the GPRS
  provided by our Telecom company is already at
  least compressed in a no lossy way,
• the downloaded page represents a worst-case
  scenario for the VWC (its dimension is not small,
  only one DNS request has to be performed and only
  two sockets have to be used).

18
VWC with the test web site

• The difference between VWC and VWCRelayOnly is
  very small. WiOptiMo search and check activities
  have only a minimum impact on the performances.
• VWC has reduced the performance gap between the
  WiOptiMoNoVwc and Dir.
• The VWC computational overhead is not relevant
  and compared with Proxy it obtains better
  results, saving the time to open new sockets and
  to send DNS requests on the CNAPT/SNAPT path.

18
19
Future works

• Optimization of the algorithm used to select the
  network provider to switch to (work in progress
  for a KTI/CTI project with SUPSI CH) (this
  will be object of a new paper by the end of
  summer 2005)
• Compression and encryption of the byte streams
  exchanged in the CNAPT/SNAPT sockets selected by
  the user (by the end of summer 2005)
• Signal to the applications, able to receipt it,
  the variation of the Internet connection QoS
  parameters caused by a switch between two
  different network providers (different bandwidth,
  packet delay, packet loss probability and so on)
  (not already scheduled)
• Porting on a PDA equipped with Microsoft Pocket
  PC 2003 Phone Edition or later (by the end of
  summer 2005)
• Mobile Voip optimization with the possibility to
  switch between IP and GSM networks (by the end of
  winter 2006)

19
20
Questions?