1. Application-aware acceleration for wireless data networks

2. Puzzle 34 prisoners, in isolation (cannot talk to each other)
Warden makes the prisoners an offer:
There is a room with a switch.
Switch is not connected to anything.
It is initially in OFF position.
I will randomly take a prisoner every day to the room.
The prisoner can do whatever he wants.
The prisoner can choose to tell me “all 34 prisoners have visited this room”
If the prisoner is correct, I will release all 34 of you
If not, you stay in prison for the rest of your lives
What is the strategy that the prisoners should use?
The prisoners are allowed to get together once to strategize

3. Puzzle Choose one of the prisoners as a “counter”
Only the counter can switch from “ON” to “OFF”
Any prisoner who visits the room, if he has not turned the switch from “OFF” to “ON” before does so if the switch is in “OFF” position
Counter counts the number of times he switches from “ON” to “OFF”
If count=33, counter will tell warden that all prisoners have visited!

4. 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?

5. 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)

6. 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?

7. 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.

8. 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

9. 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%!

10. 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.

11. 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

12. 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

13. 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.

14. 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.

15. 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.

16. 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.

17. 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)

18. 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.

19. 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?

20. 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.

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. Related Works Wireless-aware systems
Odyssey project [Noble 1997]
Coda file system [Satyanarayanan 1990]
Wireless-aware middleware and applications
WAP: Wireless Application Protocol
PIE: Pocket Internet Explorer
A3 design element related
Web prefetching [Padmanabhan 1996]
LZW compression [Welch 1984]
Out-of-order HTTP objects transmitted in UDP [Mohomed 2006]
Commercial WAN optimizers [Riverbed, etc]
There are several categories of related work. The first category is wireless-aware systems. Odyssey project focuses on system support for collaboration between OS and individual applications by letting them both be aware of the wireless environment, and adapt their behaviors. Coda supports disconnected operations for mobile hosts. These systems are generally wireless-aware, not application-aware, and do not address the problems associated with application behavior.
The second category is wireless-aware middleware and applications. WAP: is a protocol to handle web traffic for handheld wireless devices. PIE: addresses resource constraints on mobile devices. They do not optimize communication performance which is the focus of A3.
Some other work are specifically related to separate design principles. For example,some web prefetching work can fetch pages based on user’s current page (PF). These prediction-based techniques are not deterministic, meaning the prefetched data are not necessarily used. Also, by aggressively prefetching, it may actually increase the user’s response time, and incur more overhead to the network. And there are many compression techniques (AE). Typically compression techniques only consider the redundancy of one single file, and do not consider the redundancy of users or applications, which may span multiple files. ALF provides a mechanism for the applications to deal with data in application-specific manner (PF); Out-of-order HTTP objects transmitted in UDP is related to TP;
Besides these research efforts, there are also some commercial WAN optimizers. Their techniques are basicly based on Caching, and compression, and all of them are proprietary. Also, they are not aimed at dealing with problems for wireless networks.

30. 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.

31. Thanks!
Questions?

32. Prototype Applications tested SMTP (Sendmail server + email client)H 2 4 5 1
Application
Server A 3
Client NS
Emulation
Applications tested
SMTP (Sendmail server + client)
CIFS (Samba server + smbclient)
HTTP (Internet Explorer)

33. Transaction Prediction (TP)
Application software
Samba Server:
Smbclient: 2.0.7
The negotiated dialect is: NT LANMAN 1.0
SMB (Server Message Block) / CIFS
CIFS is updated version of SMB (1996/97 by MS)
NetBIOS : port 139
Raw TCP : port 445

34. Transaction Prediction (Cont’)
Samba server
TP Component
Smbclient
SMB Session Control Messages
Record States Information
SMB Open Request
Record File Size Information 1 .
Record file size info 2
If the info is not returned ,
actively probing
SMB Open Response
SMB Read ( - 16 KB )
Record Block Size Info .
SMB Read ( 16 - 32 KB )
Read Request Prediction 1 .
Predict SMB read requests
File offset 2
Store Data locally
Read a file.
TP component.
SMB Response and Data
Generated Ack
Ack Generation
SMB Response ( - 16 KB )
Read Response Processing
DATA
Supply responses according to requests

35. Why not transport layer solution (IB)
When TCP was designed
Not every apps need that
New apps
Unified Application-acceleration architecture

36. Unified architecture Unified Application-acceleration architecture
Loss-throttled Bandwidth Under-utilization
(Physical Layer) RAR
TCP-Throttled Bandwidth Under-utilization
(Transport Layer) IB
Application-Throttled Bandwidth Under-utilization
(Application Layer) TP
Application Bandwidth Competition
(User) Prioritized Fetching
Non-Reduction of Data
(Application Layer) AE

37. Motivation: Network Setup
We did the test with the help of Ixchariot, which includes three components: Ixprofile, Console, and Performance Endpoints.
IxChariot is the leading test tool for emulating real-world applications to predict device and system performance under realistic load conditions.
IxProfile, Profile is able to import captured data traffic, analyze it and then creating traffic generation scripts and streams
Endpoint
Console,
3 computers.

38. Software Architecture
The software architecture is shown. Since the design elements in A3 are to a large extent independent of each other, a simple chaining of the elements in an appropriate fashion will result in an integrated A3 architecture. Specifically, the order we propose is: TP, RAR, PF, IB and AE.
RAR operates after TP, given TP may generate new requests for data. PF manipulates the priority with which different requests are served. IB ensures that data responses are not throttled by flow control. Finally AE compresses any data outgoing.

39. Deployment with NetFilter
We present an a3 implementation that resides in userspace and uses netfilter utility in Linux for the capturing of traffic at the mobile device. Netfilter is a linux specific packet filtering utility, defines 5 hook points in linux kernel. A3 hooks are registered at the Local-in and local-out points.
While our discussions are linux centric, our discussions can be mapped on the windows operating system through the use of windows packet filtering interface.
WinpkFilter is a high performance packet filtering framework for Windows 9x/ME/NT/2000/XP/2003 that allows developers to transparently filter (view and modify) raw network packets with minimal impact on network activity without having to write low level TDI or NDIS driver code.

40. Application-aware Encoding (con’t)
The bar figure shows the effectiveness in terms of compression ratio. In the figure, the results of ten person’s using three compression methods. We can see that winRAR and winzip can compress an by a factor of 2, while AE can achieve a compression ratio of about 5.

41. TCP-ELN
reason for the loss of a packet can be communicated to the TCP sender.
If the receiver or a base station knows for sure that the loss of a segment was not due to congestion, it sets the ELN bit in the TCP header and propagate it to the source.
To avoid against wrongly marking a congestion hole as having been due to a wireless loss, it only adds a hole to the list of holes when the number of packets queued on the base station's input interface is not close to the maximum queue length.
ELN tries to detect the losses that are not related to congestion,
and send the information to the sender. Thus, retransmissions can be
decoupled from congestion control.
If the receiver or a base station knows for sure that the loss of a
segment was not due to congestion, it sets the ELN bit in the TCP
header and propagate it to the source.
Since our experiment does not introduce cross-traffic, most of the
losses are link loss, instead of congestion-induced loss. As long as
the outstanding data is not more than the BDP of the path, there is
no congestion-related loss.
So, on the sender side, it monitors the amount of outstanding data.
If loss occurs when the amount of outstanding data is less than the
BDP, the losses is considered to be caused by link loss. Thus, it
does react to this loss as normal TCP does. Such as, reducing
congestion window.

42. WTCP Rate-based rather than window-based No slow start
Uses inter-packet separation for packet control
Rate-based, Inter-packet separation. slow start
First, rate-based; The rate is based on Inter-packet separation;
Removing slow-start phase.

43. STP
The transmitter periodically requests the sender to ack the data received
Losses are detected when receiver receives explicit negative acks
Based on SSCOP
Link asymmetry, high delay;
Sender periodically requests the receiver to ack all data that it
has successfully received. Losses detected by the receiver are
explicitly negatively acked.
We improve the slow start phase by allowing sender to have larger
startup window. We also use poll messages to learn the packet loss
information form the receiver.

44. violation of layer separation principle.
We address this concern in two levels. Firstly, from fundamental standpoint, we separate the proposed design elements from deployment model, and these design elements can be incorporated into new applications by application designers. Secondly, however, given the wide deployment of these bread and butter applications, from purely practical standpoint, we feel it is necessary for end-users to deploy such a solution. End users can deploy the solution immediately and enjoy the benefits without waiting for new application’s deployment.

45. FTP FTP server  220; Login name  331 password welcome
dir listing
(Separate data channel)

46. Questions ELN webpage Application reading rate
1. Network setup is different, unclear, 2. Workload is different, not clear; 3. Checked 1997 paper, 5 files/page.
Application reading rate
Computation intensive application.
Mobile devices have more resource constraints.
Application reading rate is dynamic. BDP larger than wired networks.

47. Puzzle Three bulbs inside a room Three switches outside the room
Room initially locked
You can initially play with the switches
You then need to enter the room and be able to match switches to their respective bulbs
Devise a strategy