1. Application-aware acceleration for wireless data networks

2. Introduction Wireless Environment
High loss rate, Large delay, Low bandwidth
Works focused on developing better transport protocols for wireless environment
TCP-ELN, WTCP, STP, etc.
Novel design, deals with unique characteristics
Improves throughput significantly
Evaluation of transport protocols
Bulk data transfer, or FTP
This work is conducted in the context of wireless networks. Wireless environments, as we know, have unique characteristics, such as high loss rate, large delay and delay variation and low bandwidth. As we know, TCP’s performance is unsatisfactory in wireless environments due to these characteristics. Over the past several decades, significant amount of research has been conducted toward developing better transport layer protocols, examples of these protocols are: TCP with explicit loss notification, wireless TCP, and satellite transport protocol.
These wireless-aware protocols have novel design components that deal with the characteristics of wireless networks. They can deliver better performances when compared to original TCP. However, the effectiveness of these protocols is evaluated using bulk data transfer, or FTP application. In this work, the key question we ask is: how about other applications?

3. Analysis of Enterprise Traffic
The reason we ask this question is because these applications are actually carrying larger portions of network traffic. Here is an example showing the percentages of different types of traffics in an enterprise network. The figure is borrowed from an article in Business Communications Review. We can see that traffic corresponding file transfer only accounts for less than 10 percent, and ranks number 5 among all the traffics. The top three types of traffic are: client-server applications, -related, and web applications, and each of them accounts for more than 15% of the total traffic. Thus, we see that non-FTP applications dominate network traffic.
The same trend also holds for Internet. Although in public Internet, the traffic distribution is different, for example, P2P traffic account for largest portion today, FTP traffic still only accounts for a small percentage of the total traffic.
Thus, we see that these non-ftp applications are more important in terms of the traffic volume they carry.
Figure from Business Communications Review (April 2006)

4. How do non-FTP applications perform in wireless environments?
The question we ask in this work is: How do these non-FTP applications perform in wireless networks, and more importantly, How much performance improvements can be achieved by using wireless-aware transport protocols for non-FTP applications?

5. Evaluation Traffic generator Application protocols Wireless Networks
Ixia IxChariot
Application protocols
CIFS(Client-server), SMTP ( ), HTTP (Web)
Wireless Networks
Wireless LAN (WLAN) (5Mbps, 5ms)
Wireless WAN (WWAN) (0.15Mbps, 200ms)
Satellite Networks (SAT) (1Mbps, 1s)
Transport Protocols
TCP-NewReno, TCP-ELN, WTCP, STP
Parameters
Varying loss rates
We set up testbed to measure their performances. We did the test with the help of IxChariot. IxChariot, is a leading performance test software. It can emulate dozens of real-world applications by generating application-specific traffics, and can be used to evaluate system performance under realistic load conditions. In order to study their performances, in this work, we choose three representative non-FTP application protocols, namely, CIFS protocol for client-server applications, SMTP for -related applications and HTTP for web-related applications.
We consider three types of wireless networks, namely Wireless LAN, WWAN, and Satellite area networks by varying network parameters. For the transport protocols, Besides tcp newreno, we also consider TCP-ELN, WTCP and STP.
We perform experiments by varying several network parameters including loss rate, bandwidth delay products. In the following I will show the impact of varying loss rate on the application throughput.

6. Motivation Results: FTP
WLAN
WWAN
SAT 1
1.5 2
2.5 3 4
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9 5
Loss (%)
Throughput (Mbit/s)
NewReno
TCP-ELN
0.05
0.1
0.15
0.2
0.25
STP 6 8 10 12
0.02
0.04
0.06
0.08
0.12
0.14
0.16
0.18
WTCP
Now we proceed to show the results. FTP first, The three figures correspond to three different wireless environments. For each figure, the X axes is the increasing loss rate, and Y axis is the throughput.
The blue curves are the throughputs achieved by using TCP-NewReno, and the red curves show the throughput when using wireless-aware protocols. When using wireless-aware transport protocols, there are significant amount of improvements, ranging from 20% to more than 120%. The results mean that the design of these enhanced protocols is sufficient to deliver much better performance when FTP is used as the applications.
Significant performance improvement…
Up to 120% in satellite networks

7. Motivation Results: Other Applications
CIFS
HTTP
SMTP
Marginal performance improvement for Non-FTP applications
Less than 5%!
Now let’s look at what happened to other applications. The results of TCP-NewReno are shown using blue curves.
Then wireless-aware transport protocols. We observe that for all these applications, the performance improvements by using wireless-aware transport protocols are marginal, at most 5%!

8. Non-FTP applications see marginal performance improvements even when using wireless-aware transport protocols!
Why ?
From the results, we observe two things. First, these non-FTP applications see much less throughputs when compared to FTP; Second, for these non-FTP applications, the performance improvements when using wireless-aware transport protocols are marginal.
What are the reasons? A deeper exploration into the observations suggest that, these performance differences are not caused by fundamental design limitations of these wireless aware transport protocols, but caused by the specific behaviors of the applications under consideration.

9. Application Traffic Patterns
FTP
CIFS
Client
Server
Client
Server
Establish NetBIOS Session
Command
Positive Session Ack
Negotiate CIFS Dialect
Data
Choose CIFS Dialect
Data
User Login
User ID
Connect to Resource
Tree ID
Data
Open A File
File ID
Request Data Block 1
To identify application behaviors, let’s first examine the traffic patterns of these applications.
FTP has very simple traffic pattern. FTP client and server exchange commands on a command channel. if the command is a reading request, the server will transfer the bulk data to the client over a separate data transfer channel.
Other applications have much different traffic patters. Look at CIFS first. CIFS stands for Common Internet File System, it is a protocol used for sharing files, printers and other communications between computers. Operating CIFS involves several request/response steps. As seen from the diagram, these steps include establishment of a NetBIOS session, negotiation of CIFS dialect, user logging in, connecting to resources, and opening a file. After that, if the operation is a reading one, the client sends a request asking for a block of data. The server returns the data. If more data are needed, then subsequent requests and responses are repeated.
Data 1
Request Data Block 2
Data 2

10. Real Traces of CIFS CIFS Client CIFS Server
The above flowcharts are plotted based on documented standards. To validate the process, we also use TCP dump to capture the real traffic for the three protocols.
Here we show the packet traces of CIFS protocol. The packets captured are exchanged between a cifs client and cifs server, and the operation is reading a file from the server. The left two columns of values show the time of the packets sent and received by the client. The third column shows the packet ID, and the values here are the packet sizes.
Most of the messages on the flow chart correspond to the session control messages, including session establishment, user logging in, and opening resources, and so on, as described before. Only the last message exchange corresponds the transmission of data, which can be seen from the packet size.
CIFS Client
CIFS Server

11. Application Traffic Patterns (Cont’)
SMTP
Client
Server
200
smtp .
receiver
com Ready
HELO mail
sender
com
250
MAIL FROM :
david @ OK
RCPT TO
bod
DATA
Connect to server
End of Data
Quit
221
Service Closing
HTTP
Client
Server
200 OK
HTTP Request (
GET )
DATA
SMTP stands for Simple mail transfer protocol, is used to exchange s either between mail servers, or between a client and a server. The whole process is like following: after being connected by the client, the server responses with a 200 reply. Then the client send HELO, Mail from, recipient to, and data commands, for each of these commands, the server sends a reply.
HTTP: is the underlying protocol used by the world wide web. According to this protocol, the client first requests the HTML documents, then requests the objects contained in the HTML document one by one.
We have seen that CIFS/SMTP/HTTP has much different traffic patterns compared to FTP. After careful examination into the traffic patterns and the applications, we identify five application behaviors which affect application performances.

12. 1. Thin Session Control Messages
Application Behavior
1. Thin Session Message
Session control messages
Session establishment, logging in, etc.
Exchanged before data transfer
Different from DATA, no subsequent packets without response
Thin
Small, almost always contained in a single packet
Impact
Loss recovery only relies on timer expiration
Retransmission Time Out (RTO) has coarse minimum values (up to 1 second)
First, we notice that each application session starts by exchanging some session control messages, for example, the messages used for session establishment, user login, and requesting data.
These session control messages have two interesting properties. (1) they are sent before real DATA transmission. After a message is sent out, the sender will wait for reply from the servers. Before receiving the replies, no more messages are sent from the sender. This property is very different from the data transfer process, where as much as possible data are sent if other factors such as congestion window allow. (2) they are small, ranging from several bytes to hundreds of bytes, and are almost always contained in a single packet.
These properties lead to one problem. In TCP, the loss detection and recovery are performed in two ways. Either the sender receives three duplicate ACKs which triggers the fast retransmit mechanism, or the retransmission timer expires. For data transfer, one would expect that fast retransmit scheme can recover most of the losses with the help of successive data packets. However, for the the transmission of thin session control messages, since no successive pkts are sent after the transmission of session control messages, the sender would not be able to collect enough duplicate acks to trigger fast retransmit. Unfortunately the retransmission timers are in most Operating systems are maintained with coarse values, ranging from several hundreds ms to 1 second. Thus, the loss recovery can only rely on the expiration of retransmission timer, which unnecessarily increases the user’s response time.

13. 2. Batched Data Fetch Data transfer is performed in batches Impact
Application Behavior
1. Thin Session Message
2. Batched Data Fetch
Data transfer is performed in batches
Data is divided into objects or blocks
HTTP: each object is small
On average, several KB
CIFS: each block is small
16KB, 32KB, 64KB
Impact
Each block is fetched separately (request-response)
Transmission of each block requires one RTT
Bandwidth Delay Product of the path cannot be fully utilized
Second application behavior is the batched data fetch. That is, the data transfer is performed in batches, meaning the entire data are divided into blocks. For example, the objects fetched by http are typically of several kB. And CIFS block sizes are normally 16KB, 32KB, or 64KB.
The impact of this behavior is that: Each block is requested separately, and requires a request-response exchange – takes at least one RTT of time. This batched data fetching behavior leads to the underutilization of the bandwidth delay product of the path, and in turn, the reduced throughput.

14. 3. Flow Control Bottlenecked Operations
Application Behavior
1. Thins Session Messages
2. Batched Data Fetch
3. Flow Control
Application reading rate low
Receiver’s connection buffer fills up
TCP’s flow control can kick in
Takes time to learn updated buffer state
Impact
Throughput is limited
Limits efficacy of techniques such as fast recovery
The third application behavior is Flow control bottlenecked operations. When application reading rate is low, the receiver buffer could be frequently filled up, and the sender will stop sending any more data due to enforced flow control mechanism. Even later the receiver side has more buffer space, it takes some time for the sender to learn the information, and begin to send data.
Thus, the throughput may be seriously throttled by flow control mechanism. One more subtle impact is the during loss recovery, limited buffer size prevents the appropriate functioning of techniques such as fast recovery. According to TCP fast recovery specifications, the sender’s congestion window can grow larger when losses are detected. But due to the receiver buffer’s limitation, the sender would not be able to send more data even the congestion window becomes larger.

15. 4. Non-prioritization of Data
Application Behavior
1. Thin Session Messages
2. Batched Data Fetch
3. Flow Control
4. Non-prioritization
All data given equal importance
E.g. HTTP browsing
Web pages are big: 2.7 PC-screens on average [Source: Analysis of Comscore top 50 websites]
E.g. : 4 screens
Users only view a single screen at any time
Impact
All data compete for bandwidth equally
Increase in user response time
The fourth behavior is non-prioritization of data. For some applications, all the data are given equal importance. However, at any time, it might be true that only a subset of the data are required by applications or users.
For example, web browsing using HTTP protocol. On one hand, Most of today’s web pages are very big, having multiple full pc-screens of data. Our analysis found that the average page length is about 2.7 screens for top 50 websites. For instance, cnn.com has a webpage of more than 4 entire pc screens. On the other hand, at any time, the user can only view a single screen of data. That means, in order for a user to see the entire page, the user needs to scroll down the screen.
With the current web fetching model, all the data are fetched in a greedy fashion and competing for the limited bandwidth. This results in increased user response time. (about 1000*500 for Standard)

16. 5. Non-use of Data-reduction Techniques
Application Behavior
1. Session Control Message
2. Batched Data Fetch
3. Flow Control
4. Non-prioritization
5. Non-reduction
Redundancy in user-specific and application-specific vocabulary
E.g. SMTP sending , users typically have small “writing vocabularies”
Redundancy information cannot be fully utilized by compression techniques
Impact
Unnecessarily increases response time by not taking advantage of redundant information
The fifth application behavior is non-use of data reduction techniques. For some applications, if user-specific or application-specific information is used, it is possible to compress data better. For example, when a person composes and sends s using SMTP, he typically has a small writing vocabulary. If this information is used to compress data, applications can reduce data sizes much better.

17. Application behavior dominates performance, and renders wireless-aware transport protocols ineffective.
What can be done ?
So far we have described a set of application behaviors. We see that these application behaviors can and do dominate performance achieved, and render wireless-aware transport protocol ineffective.
A further question is: how to deal with them?

18. A3: Application-Aware Acceleration
A set of five design elements that offset “bad” application behavior
Application aware
Recognize application behavior
Perform application-specific optimizations
Application transparent
Middleware approach
No modifications to applications
We proposes a solution called A3: application-aware acceleration. A3 includes a set of five design elements, which we will describe one by one.
A3 is application aware, that means it can recognize applications, and perform application-specific optimizations. It is also application transparent, that means no modification to the applications are required. A3 solution is a middleware approach.

19. 1. Transaction Prediction (TP)
A3 Element TP
Deterministically predicts future requests, and issues them ahead of time
For protocols that divide data into blocks
Example: CIFS
Monitor session, extract file information, generate gratuitous requests to server, serve locally on subsequent requests
CIFS: Throughput
CIFS: Number of Requests
The first A3 element is TP, transaction prediction. TP can predict future requests and issue them ahead of time. This is designed for protocols that divide data into blocks. One example is CIFS.
Let us see a file transfer operation with CIFS and FTP protocol. Files are transferred from the server to a client. The first figure shows the throughput of FTP and CIFS with increasing file sizes. We see CIFS suffers from much lower throughput. The second figure actually explains the reasons. It counts the numbers of requests sent by CIFS client. The number of requests are proportionally increasing when the requested data is larger. We see that the request-response chatty behaviors cause the low throughput for CIFS.
How does TP accelerate the applications is like following. According to CIFS protocol, before requesting data from the server, the client has to send a file-open command. The server will reply to this command, and include the file size information in the reply. After that, the client will send request asking for a block of data. TP can monitor this process, and generate successive requests on behalf of the client. The server receives all these requests and sends data back. Thus, by using TP, which parallels the requests, these chatty behaviors can be removed, and in turn the performance is accelerated.

20. 2. Prioritized Fetching (PF)
Divides data into categories of different priorities, and fetches them in a prioritized fashion
Designed for protocols that treat data with equal importance
Example: HTTP
A3 Element TP PF
Prioritize content based on relevance to user/application experience, fetch more important content first, adapt if priorities change
HTTP: Data size vs Screen
The second element is Prioritized Fetching, PF. It prioritize data into different categories, and fetch high-priority data faster while fetch low-priority data slower. Then another question comes, how do we know which data are of high priority and which data are of low priority. The answer is, the data that are immediately used by users are classified as high priority data. The data that are not immediately used are treated as low priority data.
This element helps protocols that treat data with equal importance. One Example is HTTP. Current web browsing based on HTTP protocol fetches data in a greedy manner, and does not consider user’s current focus. However, the entire data on a web page is distributed on different screens. This bar graph analyzes the top 50 web pages in Internet, and shows the average size of data on each screen. We can see that each screen only contains less than 20% of the data.
Thus, PF can monitor the user’s current focus, and classify the data on the web page into different categories. It then fetches data based on the priorities of the data. As a result, the user experiences reduced response time.

21. 3. Application-aware Encoding (AE)
A3 Element TP PF AE
Uses application and user specific information to better compress data
Example: SMTP
Maintain synchronized application/user based coding tables on both sides, use codes to send information across
SMTP: Statistics for 10 users
SMTP: Usage pattern of words
AE: Use application-specific and user specific information to better compress data. To see this, let’s consider scenarios where users compose s and send them with SMTP protocol.
We made two observations: 1. The vocabularies used by users are normally small. The table shows the statistics of 10 different persons, based on 100 s sent by each person. As shown in the table, the 10 persons have vocabularies ranging from 800 to Thus, even a simple coding can achieve far less sizes than plain texts. 2. The words used by a person is not uniformly distributed. The figure shows top 5% of the words account for 50% of overall usage, and 17% of the words account for 70%.
Thus, AE can take advantage of these application-specific and user-specific information, and better compress data. Specifically, AE maintains coding tables on either side of the communication, and encodes data on the sender side, and decodes data on the receiver side. With reduced data size, the user’s response time can be decreased.

22. 4. Infinite Buffering (IB)
A3 Element TP PF AE IB
Prevents flow control from throttling application performance
Flow control never kicks in
Receiver side uses local storage to store buffer overflows, hides the effect of low application reading rate, reads from storage when buffer space opens up
CIFS: Throughput vs Application rate
IB: Prevent flow control from affecting the performances.
We use this figure to show the adverse impact of application reading rate. This figure shows the cifs throughput under various application reading rate. The blue line is the ideal throughput, which is the same as the application reading rate. The red line is the actual throughput. We can see as the application reading rate is low, the actual throughput is much lower than the reading rate, due to the impact of enforced flow control.
On the receiver side, IB uses local storage as the extended tcp connection buffer. The underlying reason for doing so is that reading from local secondary storage is faster than reading from wireless networks, which is typically true. With IB, the sender has a perception that the receiver has infinite buffer space, thus flow control mechanism never kick in. Thus, IB can hide the effect of low application reading rate, and ensures the throughput is not throttled by flow control mechanism.

23. 5. Redundant and Aggressive Retransmission (RAR)
A3 Element TP PF AE IB
RAR
Helps protect session control messages from losses
Does not apply to data transfer
Packet-level redundancy and aggressive retransmission for thin messages
SMTP: Throughput
The fifth A3 element is called RAR, stands for Redundant and Aggressive Retransmission. It helps to protect thin session control messages from losses.Note that only thin messages require RAR due to two reasons: For DATA packets, their loss recovery can be pretty well masked by subsequent packets. Overheads of performing RAR on data packets would be too big.
This figure shows the throughput of SMTP under lossy conditions. The red line is the actual SMTP throughput, and blue line is the ideal throughpu. The ideal throughput is calculated as the physical available bandwidth. We can see a 35% drop in the real throughput as loss rate increase to 7%, which is much higher than ideal case. These results show that the losses have much adverse effect to the throughput due to the traffic patterns we identified above.
RAR recognizes thin messages, and perform Packet-level redundancy and aggressive retransmissions. By performing RAR, the losses of session control messages, and in turn the adverse impact on the applications can be pretty well prevented.

24. A3 Deployment Model Client side is a software module
Server side can be software module or a packet processing appliance
A3• solution, but with limited functionality
A3 deployment model is shown in this figure.
Since A3 is a platform solution, it requires two entities at either end of the communication session. At the mobile device, A3 is a software module that is installed in user-space. For linux system, one way to implement this module is to use NetFilter utility. Netfilter utility can capture live network traffic, and process them in user space. At the server side, while A3 could be deployed as a software module on all servers, a more elegant solution would be to deploy a packet processing network appliance.
However, if the mobile device communicates with a non-A3 enabled server, A3 can be used as a point solution with less effectiveness.

25. Evaluation Setup Application Emulator (AppEm) A3 Emulator (A3Em)
Wireless Network Emulator (WNetEm)
We use emulation method to evaluate the performances. The test bed has 3 desktops running on Fedora Core 5 with linux 2.6 kernel. There are three emulators in the topology.
Running on the two end machines are the custom-built application emulators. They are used to generate application traffics based on IxChariot scripts and documented standards. The intermediate machine runs on NS2 emulation mode, and actually serves two purposes. first, it implements the A3 module on each side. Second, it implements the network emulation. Under emulation mode, ns2 captures the on-going live network traffic. The captured packets are fed into the ns2 topologies, after processing, they are injected into the network again.

26. Integrated Evaluation (WWAN)
CIFS
SMTP
HTTP
We present the results of the integrated evaluation for WWAN. For each of the protocols we considered, all applicable principles are applied. Confidence Interval 90%.
For CIFS, TP RAR and IB are applied. This figure shows the throughput of CIFS with increasing file sizes. The first trend we see is that A3 achieves larger improvements with larger data file. With 10 MB file, the improvement is 70%. Also, we notice that for larger files, A3 can help deliver better performance.
For SMTP, AE, RAR and IB are applied. With 10 KB size, up to 100% of improvement are observed.
For HTTP, the instead of showing the throughput, we show the response time, because PF works by fetching useful data first, thus the raw throughput may be the same, but the response time is reduced.
The performances when using the integrated A3 principles is higher than when any individual principle is employed in isolation.

27. Summary
Wireless-aware transport protocols are evaluated using FTP application
Non-FTP applications exhibit different behavior
Application behavior can dominate performance
A3 consists of a set of application-acceleration principles with a practical realization model
To summarize. In this work, we observe that most wireless-aware transport protocols are typically evaluated using FTP applications. We also find that non-FTP applications have much different application behaviors, and these behaviors can dominate the performances and render any improvement achieved by using wireless aware protocols ineffective.
To deal with the adverse impact of these application behaviors, we propose a set of application-acceleration techniques, and also describe an application-aware solution.