Now, possibly this question will be irrelevant in a couple of years' time if we all move to flatrate mobile data (including roaming), but for now, I'm surprised it's an issue that hasn't cropped up more often.
I've just got a press release from LogicaCMG about their web compression ("optimisation") product which is essentially a proxy server which squeezes down web images & generally monkeys around with content to make it render better on a small screen. No, this isn't a particularly new concept, various others have done it in a similar way, or via on-device client software like the Opera Mini client/server approach. Yes, there's also a bunch of question about whether I, the user, am happy (or even know that) my expected pristine Internet experience is being filtered & squished & re-ordered according to what the network thinks I'd prefer, if I can get it a bit quicker. That's a topic for another day (for example, how does it know what screen resolution I can display? does it adjust for what browser I'm using? what happens with Flash and AJAX and all that good stuff?)
But how about the question of what this - and other techniques, think caching or multicast - means for the billable traffic flow. Am I billed for the actual bits that go over the air to my phone? Or the raw pre-optimised content going into the server? What about if some of the content is cached locally at the base station? do I & multiple others pay for that as well? (various people have suggested that this is an option). Or if some stuff gets multicast? Is there any "overhead" that I don't get to use or even see - am I paying for that too? No big deal if it's flatrate of course, but I pain if it's €10 a MB on international 3G. Or if it's a mid-size bundle, how do I know my consumption is being judged accurately?
I'm reminded of my Yahoo mail. I know that if I get a 3MB mail attachment with a 2-line text email, for some reason Yahoo claims that I received 4MB or 4.5MB in total into my inbox. Eh? As I'm not paying for it, I'm not really bothered. But I certainly would if a mobile operator tried to pull the same trick & then charge me by volume.
Now, lots of phones have a data "meter" which shows total traffic in & out - but it doesn't generally split this by port number, so you don't know what's going to a "free" application (from the data traffic perspective) like MMS or even the operator portal site, and what's charged at off-portal rates.
I would have thought a 3rd-party solution for this sort of thing would be highly relevant for applications like push email, especially for businesses whose staff roam a lot. Do you have an audit trail for your roaming traffic?
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
Sorry to say but your posting seemed quite clueless. Some comments:
ReplyDelete- Network will bill you based on the compressed content, of course. Charging is done typically by SGSN or GGSN.
- Content is never cached by basestation. I don't understand what you meant with that?
- EMail attachments use MIME encoding which causes overhead somewhere around 30%
- Screen resolution or type of user client can in some cases seen from HTTP request
Hmmm. Interesting point on the MIME encoding, I didn't know that - shame the Yahoo support people didn't know the answer when I'd queried it the observation in the past. Fair point on the SGSN/GGSN charging too, although what happens with multicast when MBMS arrives?
ReplyDeleteI've had several separate conversations in the past 3 months discussing the potential for caching content at the edge of the cellular network, or doing an Akamai-style GGSN bypass type approach. Can't say I'm convinced, but it's definitely being talked about.
I'm not convinced about the screen res being predictable - can HTTP really say "this is an Opera browser running on a 352x412 screen with 18-bit colour depth, so please don't compress images too much"?
It's not MIME that adds the overhead per se, but the fact that attachments are typically base64-encoded to make them 7-bit-clean.
ReplyDeleteHTTP is pretty extensible. Many specialised agents already send device information headers that can be picked up by any proxy along the way, or indeed the web server. All it'd take would be headers reading:
X-Screen-Res: 352x412@16
X-Proxy-Compress-Preference: medium
The developer of the user-agent can make it send whatever it likes. (iMode clients send all manner of stuff along these lines, for example, as does NetFront on the PSP)..
Regarding how to recognize screen resolution,
ReplyDeletePlease check this out:
http://en.wikipedia.org/wiki/UAProf
So mobile terminals typically put an URL to the user agent profile file in the HTTP request. If the server doesn't have a cached version of the file it can receive it from the URL.
Here you can see some examples of the depth of the information contained in UAProf - it's quite extensive:
http://w3development.de/rdf/uaprof_repository/
BUT, personally I think with current relatively CPUs in the mobile devices & 3G it would be wrong to mangle the pages in the network.
It's not the CPUs, though, it's the data transfer costs. The casual users, the ones that the networks want to get hooked on mobile Internet services, typically aren't on flat-rate data plans (especially, say, in the UK where a huge proportion of mobile users are pre-pay customers) will care about the per-byte costs, because ultimately they're paying for it.
ReplyDeleteAdd to that the fact that most web agencies are still ignoring web standards and churning out horrifically heavy mark-up and are often ignorant of proper (device-agnostic) practices, which means that pages are a bucketload bigger than they need to be to express the content that they hold, and pay-per-byte users suffer because of it.
On top of that, non-3G users have to deal with high-latency links wherein each request/response round-trip is slow, even if the bandwidth available is relatively plentiful: pipe-lining the requests into a custom protocol that not only compresses the data (to save costs) but also fetches and sends the page pre-requisites server-side automatically (to speed things up) is fairly benefit-heavy.
The CPUs haven't been the issue for mobile UAs for a long time, not unless you want a Flash-heavy desktop-style ‘experience’ on your phone (arguably, this is what would attract people, but the applets would have to be properly designed for mobile platforms in any case… it ceases to be a web browsing issue fairly quickly).
Re: additional headers in HTTP requests:
ReplyDeleteIn fact, some popular mobile phones send so much more device capability information that it may be seen as an overhead problem.
So yes, it is mainly up to Web application developers to use this to adapt the Web content. However, the provided information varies strongly between phone vendors or even models, and thus may create an opportunity for some middleware / Web development platform.