Hacker News Reader

Comment by JangoSteve | Hacker News Reader

That's not true. The alternative is to have the Android request the data from the DHCP and only then have the tethering DHCP respond with the flag. Keep in mind that, if you're the one programming the tethered device to obey this flag, then you have the ability to make the tethered device request the flag in the first place.

Also, once it's on a request-only basis, it shouldn't be a stretch to make it possible to disable via a configuration setting.

The above two points I believe were the point of the OP.

View on HN

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]

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.

If I understand the article correctly, the disabling of sync etc. is done by the device CONNECTING to the hotspot, not the device providing the hotspot. The hotspot just notifies downstream users "hey, I'm on a metered connection". If you connect with your laptop, it ignores the flag and sucks up as much data as you want it to.

The only point about your android phone PUSHING the flag, is that it's not a non-standard implementation of the protocol. If you want to disable this on your phone, you have to tell it to ignore that flag, rather than tell it to not request it.

Reply on news.ycombinator.com