this paper was submitted on
4 points (100% like it)
4 up votes 0 down votes

papers

subscribe8 readers

Welcome to the public review site of papers appearing in MobiSys 2012. Here you can find the public review written by a PC member for each paper and the authors' rebuttal to it. You can comment on any of them or add your own opinion. Finally you can vote to "like" or "dislike" a paper by clicking the up or down arrows next to its title.

all 5 comments

[–]cedichou 1 point2 points ago

sorry, this has been archived and can no longer be voted on

excellent paper, full of terrific ideas!

[–]ConferenceQA 1 point2 points ago* 

sorry, this has been archived and can no longer be voted on

Asker Affiliation: KAIST

Question: MicroCast has a lot of requirements, for example, a number of people should be together, watching the same video, and watching on different devices. Doesn't this limit the practicality of this solution?

Answer: This is actually a very common scenario -- you are out with friends, and you would like to watch a video. When you have more than ~4 people it becomes very hard to watch on the same device. We solve this problem. Additionally, even if you are watching on the same device, the other phones act as accelerators, speeding up the download speeds for the device displaying the data.

[–]athina 0 points1 point ago* 

sorry, this has been archived and can no longer be voted on

Regarding the question about the "requirements", how "common", the presentation provided statistics showing that the "micro"-setting is actually quite common: 1 in 5 YouTube users view videos on their mobiles daily and 50% of them watch videos together with their friends in person.

On a more general note, this paper focuses indeed on the "micro"- setting (small number of users, within proximity of each other, watching the same video at the same time but from different devices) and optimizes the design for this particular setting (taking into account device-to-device links, broadcast, etc). On the other extreme, one could envision a more general framework that fits all scenario. This is not only more difficult to design, but also may end up being not relevant to any particular application.

[–]ConferenceQA 1 point2 points ago* 

sorry, this has been archived and can no longer be voted on

Question: When you measured battery you were including total power, including display and system power. What is the power consumption of just the network/implementation specific code?

Answer: Unfortunately this plot does not differentiate, and it is actually somewhat difficult to attribute power to the specific tasks or hardware.


Question 2: What is the power difference between the AP and other nodes?

Answer: The access point uses more energy, since it is always on, but unfortunately we don't have that data in this presentation. It shouldn't be significant.

[–]athina 0 points1 point ago

sorry, this has been archived and can no longer be voted on

Regarding the first question: the take-home message from the battery measurements is that microcast spends almost the same energy as the naive schemes, but finishes the download of the same file much faster. Therefore, whatever the exact cost of network coding is, it is negligible compared to the savings from using the network interfaces less.