Hacker News Reader

Comment by remosi | Hacker News Reader

Having written the document that this links to, my goal of pointing out the surprising behaviour with android not requesting an attribute it cared about was to avoid other people banging their heads against this problem when they tried to implement this solution.

This is obviously an incomplete feature: The TODO shows that they intended to actually plumb through the "metered" bit from the upstream interface, but never implemented it.

And this is a default, I suspect you can override this, either in the individual applications, or by disabling the "hotspot" option in the buried menu.

Yeah, it's a bit annoying if it's your default way of getting to the internet, but it's at least not going to cost you a massive pile of money as it sync's everything before you have a chance to turn off all the syncing. This way you can at least turn the syncing on again later if you're ok with it.

[Edit: speling]

View on HN

It'd be nice if there was a programmatic way for the upstream bandwidth provider to communicate cost-per-gigabyte. That way the client wouldn't have to use hackish workarounds to guess if it's on metered bandwidth-- it'd know so.

If cell networks communicated cost-per-gigabyte, then a dual-SIM phone could automatically switch to the cheaper data. This would cause a crash in bandwidth prices, which is why the phone companies would have to be forced into it, probably by the FCC.

After thinking about it for more than three seconds, there's actually two figures of merit: cost-per-gigabyte and width of the desired network connection in bits/s. A gigabyte transfered at a kilobit per second is a lot cheaper than one sent at a megabit/s. Sending a text message from a phone is cheaper than a voice call, which is cheaper than watching a 720p video. So you'd have to have some kind of sliding scale, adjusted by how many other clients there are in the cell, and how much bandwidth they're using...

This seems all very obvious. Has this scheme been described in an RFC from the 80s that I've just never heard of?

There are complications, some IP's might be free, some might be cheap (caches, local peering), some might be expensive (transit). The price might vary on time of day (a lot of eyeball networks are near idle when everyone's asleep). The price might vary on the DiffServ bits. Then there's the question of what is it billed in (what if one connection is billed in GBP and one is billed in USD?). Maybe one connection has the first 1G free. Should you advertise the entire connection as being free until you hit that 1G, then advertise it as the overage? Or should you do something to try and make sure that the 1G lasts the entire billing period? If it's a peering connection, maybe it's free so long as the in:out byte ratios are within 10%, so how do you represent the price of that?

But for the simple version, I think RSVP is supposed to kinda support this, but it would probably be difficult to shoehorn in, even ignoring all the stuff I mentioned above.

Reply on news.ycombinator.com