
Give in to Procrastination and Stop Prefetching (2013) [pdf] - lainon
http://people.csail.mit.edu/lenin/papers/Procrastinator-Paper-HotNets13.pdf
======
wgjordan
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.

------
rixed
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?

~~~
toyg
_> 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
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.

~~~
rixed
This could be easier: your phone could query periodically your balance(s) and
figure out the price of various connections. All you need for this is telcos
providing real time balance in a standard protocol.

~~~
wutthrow
Spoken like the generation taught to not conserve data. /s

The phone itself could easily record the returned file size of all requests
within a threshold. My old Note3 has these alerts built in with separate
limits for mobile vs wifi.

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

~~~
tunap
Reliance=revenues

Able=self-reliance

<Monop/Oligop> Corporation, Inc is not remotely interested in the latter.

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

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

------
lainon
Related: [http://people.csail.mit.edu/lenin/papers/Procrastinator-
Pape...](http://people.csail.mit.edu/lenin/papers/Procrastinator-Paper-
MobiSys14.pdf)

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

