Authors: Lenin Ravindranath, Sharad Agarwal, Jitendra
Padhye, Chris Riederer
Many applications such as shopping, socializing improve
their performance by prefetching. They do not care about data usage. It
consumes 600KB to simply checking the temperature in a weather application. It
downloaded 30 objects in this process include very large radar image. The
applications do so because the cellular network is slow.
However, the author point out that there is a need to stop
prefetching due to limited data plan or roaming to other networks. So they
presented Procrastinator that could decide when to fetch each network
object.
The Procrastinator makes decision by taking several factors
into account, include whether the user is on WiFi or cellular network, how many
bytes are remaining in the user’s data plan and whether the object is needed at
the present time.
The procrastinator does not need to have the source code for
the applications. It could achieve its
goal by trap system calls and inject custom codes. In addition, it does not
require OS changes.
The author carried on an experiment on 9 cellphones for 6
weeks. The result of the experiment is significant. The system could achieve up
to 4 times saving in bytes transferred.
The paper revealed an interesting and common problem on
cellphone users. The authors regard the system as a significant improvement to
current cellphones by providing a useful function with little overhead.
Q: There may have side effects on the server such as more
http requests.
A: It won’t pose too much pressure on the server. Just
process the request as usual.
Q: Do you think it can be applied in other useful cases such
as taken other people into consideration while sharing the same network?
A: Yes.
Q: Do you think it will impair the user experience? Did you
carried out any user study on this?
A: For WiFi networks the impairment is very small.
Q: Do you process any post requests or TCP connection?
A: Yes.
Q: Hacking my binary does not make me feel good.
A: It won’t cause bad things for you.
Q: why not provide prefetching API in the system? It could
also provided a bounded delay for the software.
A: That requires too much effort. Actually we’ve developing an IDE which can
warn the developer of improper prefetching.
Some of the Q&A listed above are incorrect.
ReplyDeleteWe do not procrastinate any HTTP POST nor TCP nor UDP traffic -- those behave as the app developer intended.
App developers can run our system on their app binary and then run the resulting app binary to observe its behavior and verify it does not behave unexpectedly.
We have studied the impairment on users -- the latency graph is in the paper. On LTE and Wi-Fi, the additional latency penalty is usually small, under 100ms. We believe this <100ms latency penalty is small compared to the benefit of reduced data consumption, for those users on small data plans.
Our system does not trap system calls. It instead rewrites app binaries to replace API calls with calls into our own runtime that manages network transfers for the app.
ReplyDelete