6 ms·

Give in to Procrastination and Stop Prefetching (2013) [pdf]

118 points by lainon 9y ago

lainon 9y ago
Related: http://people.csail.mit.edu/lenin/papers/Procrastinator-Paper-MobiSys14.pdf http://people.csail.mit.edu/lenin/papers/Procrastinator-Pape...
- ranit 9y ago
  Did you intend to post a different link here? This is the same pdf as the one you submitted.
wgjordan 9y ago
Abstract – Generations of computer programmers are taught to prefetch network objects in computer science classes. In practice, prefetching can be harmful to the user’s wallet when she is on a limited or pay-per-byte cellular data plan. Many popular, professionally-written smartphone apps today prefetch large amounts of network data that the typical user may never use. We present Procrastinator, which automatically decides when to fetch each network object that an app requests. This decision is made based on whether the user is on Wi-Fi or cellular, how many bytes are remaining on the user’s data plan, and whether the object is needed at the present time. Procrastinator does not require developer effort, nor app source code, nor OS changes – it modifies the app binary to trap specific system calls and inject custom code. Our system can achieve as little as no savings to 4X savings in bytes transferred, depending on the user and the app. In theory, we can achieve 17X savings, but we need to overcome additional technical challenges.
justinsaccount 9y ago
> prefetching can be harmful to the user’s wallet when she is on a limited or pay-per-byte cellular data plan Sure, but if you are not on a limited or pay-per-byte data plan, then prefetching a large block block of data so the radio can go into low power mode for a while is more helpful.
- snakeboy 9y ago
  From the abstract, > This decision is made based on whether the user is on Wi-Fi or cellular, how many bytes are remaining on the user’s data plan, ... so it sounds like your scenario is already accounted for and you'd be flagged as a "data-heavy" user, for which prefetching would be enabled.
  - dandyrandy 9y ago
    The network layer is not the application programmers problem. I am requesting data because I want to make my application responsive. I should take into account exactly what is a "good" amount to request or what data is most likely to be requested anyways but alot of prefetching has to do with making the first load faster. So if you decide to not prefetch then many applications will force the download on the first request... Im not concerend with wifi just if the user is connected or not. If they are connected then im trying to make the resource fetching as efficient as possible which will scale from wifi and up.
    - deleted 9y ago
      [deleted]
rixed 9y ago
I don't want to dismiss this work that I find interesting but still there is something sad about it. Estimating the cost of a connection can hardly be done without a change in the transport protocols, because the device do not know the cost of a fetch just by looking at the type of network it is connected to. Think about WiFi hotspots to cellular network. Think about data bundles. This is way easier to address in the transport protocol. Why can't we spend any effort fixing the root causes of anything and instead treat every early tech as a given and spend so much effort in developing workarounds?
- jonreem 9y ago
  > Why can't we spend any effort fixing the root causes of anything and instead treat every early tech as a given and spend so much effort in developing workarounds? Network effects.
- toyg 9y ago
  > a change in the transport protocol Deploying network infrastructure is the hardest and most expensive element of networking. You want to do it as little as humanly possible, and anything that can be retrofitted on top of already-deployed hardware is an instant winner. Changing network protocols would likely require hardware replacement all over the place.
  - marvy 9y ago
    Now you made me think. I agree this sounds really hard, but it's not clear that this requires hardware changes. After all, transport protocols are written in software. In fact, I don't think that this needs changes to the transport protocol either. Consider, your ISP knows most of this information. For instance, if you have 2 GB of 4G cell service and then it throttles to 3G, then the cell company must have real time info of how much data you have left, or they would not be able to throttle you. They will often give you an app so you can check how close you are to the limit. The only trouble is that there is no STANDARD way to ask them any of this. So make one up. This is one of the few cases where network effects mostly take care of themselves. Here is a straw man proposal. Feel free to bike shed this. Let's say we extend DCHP so that in addition to giving you the default gateway, it also gives you cost parameters for the current connection, or possibly the IP address of who to ask for the cost. If the network supports this, the OS can find out when connecting and then provide it to apps via an API. If the network doesn't support it, the OS can still expose the API, but fall back to heuristics such as whether you're on cell or Wi-Fi. Of course, the user typically knows what they are paying, so you should allow them to override the heuristics and supply real data. The apps need not know whether the data came from the network of from heuristics or the user.
gjjrfcbugxbhf 9y ago
This should be based on whether the connection is marked as metered rather than WiFi Vs cellar. I s sometimes need to tether one device to another - a risky thing to do with a limited but high speed data plan and a second device that will happily use 100s Mb of data in a few minutes.
- gizzlon 9y ago
  Sure it can happen but I have never seen a "normal person" use tethering. My guess is that you could pretty much ignore it if you're making something for the general public.
  - jstanley 9y ago
    If you cripple your software just because the average user isn't a power user, there will be no way for average users to become power users because there's no advantage to doing so.
    - deleted 9y ago
      [deleted]
    - tunap 9y ago
      Reliance=revenues Able=self-reliance <Monop/Oligop> Corporation, Inc is not remotely interested in the latter.
  - Jedd 9y ago
    This may be a regional thing, or your friends skew towards non-normal. Almost everyone I know understands tethering, and is comfortable using it. I'm in Sydney, Australia, where free wifi hotspots are perhaps less common than your part of the world, the people I know are not (to my knowledge) abnormal, mobile data services are typically fast, but costs are also quite high. It is a source of some frustration that devices connected to a tether will assume 'wifi therefore unmetered' and do all the non-time-critical stuff (such as application updates) that you'd really rather that they do on a genuinely unmetered wifi access point (eg. home cable or ADSL) later on.
jplayer01 9y ago
This is pretty interesting. However, they mention their initial version is for Windows Phone. Why? Completely wasted effort on an insignificant user base.

118 points by lainon 9y ago

Related: http://people.csail.mit.edu/lenin/papers/Procrastinator-Paper-MobiSys14.pdf http://people.csail.mit.edu/lenin/papers/Procrastinator-Pape...

ranit 9y ago
Did you intend to post a different link here? This is the same pdf as the one you submitted.

wgjordan 9y ago

Abstract – Generations of computer programmers are taught to prefetch network objects in computer science classes. In practice, prefetching can be harmful to the user’s wallet when she is on a limited or pay-per-byte cellular data plan. Many popular, professionally-written smartphone apps today prefetch large amounts of network data that the typical user may never use. We present Procrastinator, which automatically decides when to fetch each network object that an app requests. This decision is made based on whether the user is on Wi-Fi or cellular, how many bytes are remaining on the user’s data plan, and whether the object is needed at the present time. Procrastinator does not require developer effort, nor app source code, nor OS changes – it modifies the app binary to trap specific system calls and inject custom code. Our system can achieve as little as no savings to 4X savings in bytes transferred, depending on the user and the app. In theory, we can achieve 17X savings, but we need to overcome additional technical challenges.

justinsaccount 9y ago

> prefetching can be harmful to the user’s wallet when she is on a limited or pay-per-byte cellular data plan Sure, but if you are not on a limited or pay-per-byte data plan, then prefetching a large block block of data so the radio can go into low power mode for a while is more helpful.

snakeboy 9y ago
From the abstract, > This decision is made based on whether the user is on Wi-Fi or cellular, how many bytes are remaining on the user’s data plan, ... so it sounds like your scenario is already accounted for and you'd be flagged as a "data-heavy" user, for which prefetching would be enabled.
- dandyrandy 9y ago
  The network layer is not the application programmers problem. I am requesting data because I want to make my application responsive. I should take into account exactly what is a "good" amount to request or what data is most likely to be requested anyways but alot of prefetching has to do with making the first load faster. So if you decide to not prefetch then many applications will force the download on the first request... Im not concerend with wifi just if the user is connected or not. If they are connected then im trying to make the resource fetching as efficient as possible which will scale from wifi and up.
  - deleted 9y ago
    [deleted]

rixed 9y ago

I don't want to dismiss this work that I find interesting but still there is something sad about it. Estimating the cost of a connection can hardly be done without a change in the transport protocols, because the device do not know the cost of a fetch just by looking at the type of network it is connected to. Think about WiFi hotspots to cellular network. Think about data bundles. This is way easier to address in the transport protocol. Why can't we spend any effort fixing the root causes of anything and instead treat every early tech as a given and spend so much effort in developing workarounds?

jonreem 9y ago
> Why can't we spend any effort fixing the root causes of anything and instead treat every early tech as a given and spend so much effort in developing workarounds? Network effects.
toyg 9y ago
> a change in the transport protocol Deploying network infrastructure is the hardest and most expensive element of networking. You want to do it as little as humanly possible, and anything that can be retrofitted on top of already-deployed hardware is an instant winner. Changing network protocols would likely require hardware replacement all over the place.
- marvy 9y ago
  Now you made me think. I agree this sounds really hard, but it's not clear that this requires hardware changes. After all, transport protocols are written in software. In fact, I don't think that this needs changes to the transport protocol either. Consider, your ISP knows most of this information. For instance, if you have 2 GB of 4G cell service and then it throttles to 3G, then the cell company must have real time info of how much data you have left, or they would not be able to throttle you. They will often give you an app so you can check how close you are to the limit. The only trouble is that there is no STANDARD way to ask them any of this. So make one up. This is one of the few cases where network effects mostly take care of themselves. Here is a straw man proposal. Feel free to bike shed this. Let's say we extend DCHP so that in addition to giving you the default gateway, it also gives you cost parameters for the current connection, or possibly the IP address of who to ask for the cost. If the network supports this, the OS can find out when connecting and then provide it to apps via an API. If the network doesn't support it, the OS can still expose the API, but fall back to heuristics such as whether you're on cell or Wi-Fi. Of course, the user typically knows what they are paying, so you should allow them to override the heuristics and supply real data. The apps need not know whether the data came from the network of from heuristics or the user.

gjjrfcbugxbhf 9y ago

This should be based on whether the connection is marked as metered rather than WiFi Vs cellar. I s sometimes need to tether one device to another - a risky thing to do with a limited but high speed data plan and a second device that will happily use 100s Mb of data in a few minutes.

gizzlon 9y ago
Sure it can happen but I have never seen a "normal person" use tethering. My guess is that you could pretty much ignore it if you're making something for the general public.
- jstanley 9y ago
  If you cripple your software just because the average user isn't a power user, there will be no way for average users to become power users because there's no advantage to doing so.
  - deleted 9y ago
    [deleted]
  - tunap 9y ago
    Reliance=revenues Able=self-reliance <Monop/Oligop> Corporation, Inc is not remotely interested in the latter.
- Jedd 9y ago
  This may be a regional thing, or your friends skew towards non-normal. Almost everyone I know understands tethering, and is comfortable using it. I'm in Sydney, Australia, where free wifi hotspots are perhaps less common than your part of the world, the people I know are not (to my knowledge) abnormal, mobile data services are typically fast, but costs are also quite high. It is a source of some frustration that devices connected to a tether will assume 'wifi therefore unmetered' and do all the non-time-critical stuff (such as application updates) that you'd really rather that they do on a genuinely unmetered wifi access point (eg. home cable or ADSL) later on.

jplayer01 9y ago

This is pretty interesting. However, they mention their initial version is for Windows Phone. Why? Completely wasted effort on an insignificant user base.