Give in to Procrastination and Stop Prefetching (2013) [pdf] | Hacker News Reader

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

people.csail.mit.edu

118 pointslainon26 comments

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.

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?

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

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

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.

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.

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.

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.

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.

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.

Reliance=revenues

Able=self-reliance

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

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.

Same here. I've talked with multiple untechnical people who have managed to tether their iPads to their iPhones without problems.

Plug in your phone to your laptop and it works, no need to fiddle with wifi.

You're replying to someone talking about tethering their tablet onto their phone by wifi access point ... and suggesting they plug their phone into their computer.

I have experimented - in both Debian and Windows 7 - using plugged-in / USB connectivity, but a) it's a bit spotty, b) it means I need a cable connection and that's often not ideal when on the go, c) it doesn't (as noted) work with tablets, and d) it doesn't solve the underlying issue of slave devices thinking they have non-mobile(3g,4g,lte,etc) network connectivity and sucking down lots of data.

I'd posit that the majority of road warrior types know how to tether.

In my extensive work travels over the last decade I was surprised how many do not for reasons other than ignorance. In the US, the ISPs explicitly & implicitly denying tethering usage made for a very confusing time late 2000's/early 2010's. When VZW(and the other big 3, I presume) gobbled up the smaller competitors they banned tethering, then charged extra for it(after or until the toothless FCC intervention?). Masking user agents, creating on-site APs out of old linux laptops+Mobile Data USB and the flaky USB data port enabled routers worked around these restrictions well enough. Have these policies been changed by the providers to where it is simple for average users w/out system tweaks or custom ROM features?

I normally have unlimited data (well several terabytes a month), however when travelling outside the eu this drops to something tiny (200mb). I turn off roaming in those cases, however turn it on when I need things like uber, Citymapper, etc.

In Citymapper I'd like it down download and cache maps when on wifi or when in the uk, but only do the minimum when roaming.

On laptops likewise, sometimes a connection is metered - not just tethered, but wifi on trains/planes, and even some home connections.

Determining when a device is on a metered connection or not is the tricky option, probably inpossible. Perhaps something device manufacturers could incorporate into network settings (a metered/non metreed flag on the connection)

Windows 10 does this, though it required users to explicitly mark what is metered.

> Determining when a device is on a metered connection or not is the tricky option, probably inpossible. Perhaps something device manufacturers could incorporate into network settings (a metered/non metreed flag on the connection)

I think that your second sentence contradicts your first. Making the determination automatically is, indeed, probably tricky; but making the determination by consulting a user-set flag is trivial. I'm too wedded to my Mac to commit to a Windows machine, but I love that Windows 10 has such settings (necessary to prevent it from auto-updating), and wish I could make my Mac do it.

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

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

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.

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.

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

Reply on news.ycombinator.com