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?
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?
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.ReplyDelete
We 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