Dave Taht points out http://www.bufferbloat.net/ which looks very interesting!
Why mobile apps suck when you're mobile (TCP over 3G)
31–40 of 71 posts
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#32There were plenty of wireless-optimized TCP replacements proposed back in the days when WAP and XHTML Mobile were the hottest things around, but none took root as operators, web servers and browsers needed to adopt them in tandem. Now that smartphone apps are widespread and someone developing a service can control both sides of the connection, there's definitely room for someone to devise a really good TCP replacemen…
I think this is a really good idea. Startup? PhD thesis?
Do tell how you reckon a start-up could bring to popularity, let alone monetize a new Internet protocol?
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#33There were plenty of wireless-optimized TCP replacements proposed back in the days when WAP and XHTML Mobile were the hottest things around, but none took root as operators, web servers and browsers needed to adopt them in tandem. Now that smartphone apps are widespread and someone developing a service can control both sides of the connection, there's definitely room for someone to devise a really good TCP replacemen…
The mobile OS should be able to fix this. One method would be to disable the reliable delivery mechanism in the 3G code. Another method would be to use huge retransmission timeouts at the TCP level for connections going over 3G, so the TCP level seldom retransmits packets. If the 3G implementation provides completely reliable connections, the OS could fake the TCP implementation and just use that implementation direc…
The 3G connection does not aim to provide completely reliable "connections" -- it aims to provide an as-reliable-as-it-can data link, given channel conditions and configured transmission parameters (which are to some extent controlled by the RAN). If the error rate seen by the channel decoder is too high, it will drop a frame. There is an ARQ mechanism in the MAC layer to try to compensate so that the higher layers don't see the loss, but it implies some delay and also has limits -- i.e. at some point losses due to bit errors injected by the channel may manifest in lost frames and IP packets.
The L1 and MAC of 3GPP are generally implemented in an ASIC and not necessarily visible to the OS. Many of the parameters are dictated and controlled by the RAN (operators are picky and try to control things so that handsets can't misbehave and crap all over the other users in a cell), so the OS doesn't get a look in -- i.e. I don't think it's possible to turn off the 3G error recovery mechanisms.
Disclaimer: I used to work at L1 so someone with more detailed knowledge the MAC and higher layers of the 3GPP stack could give a better idea of what happens when the MAC ARQ limits are hit.
Summary: 3G was designed more than 10 years ago and is showing its age. User requirements have shifted, but standards can't evolve that quickly. Maybe LTE will help provide the user experience for today's apps... question is whether it will be widely deployed in time to matter.
EDIT: updated for clarity and spelling.
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#34This is partly why I'm so interested in publishing information at the DNS level (i.e. .tel) - you get to use UDP (or TCP failover), plus other awesome benefits. You can do other innovative things with DNS too.
Of course, that does depend on DNS having a protocol to run over. What we really need is a DWIW protocol suite at each layer.
Yep, but the point I was trying to make is that DNS over UDP works well today.
It's also worth remembering that most of the world has 2G connectivity. Heck, even I'm 2G most of the time (rural UK).
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#35Earlier quoted context omitted.
Faster travel meaning you are passing in and out of cells more often, and you are more likely to be passing through areas with bad coverage either for man-made geographical reasons (a steep embankment between you and most of the towers in range for instance) or because your route is more likely to take a straight-ish line that may pass through a pretty uninhabited area that is ether completely unserviced by the cell…
the area of each cell typically increases when you move out to sparsely populated areas with vast expanses of land. thereby, minimizing number of handovers (cell-to-cell) that might be happening.
Aye, but that is what creates the "distance from tower" problem of getting poor signal quality due to normal attenuation over distance and the larger number potential shadow/interference causing things between the tower and you.
There are a number of places where trains skip around at a goodly speed in what is probably a packed area by way of phone cells, so there will sometimes be a significant number of cell-to-cell hand-offs. Having said that, as I grew up (well, more-or-less) before mobile phones were common I'm still slightly impressed that the whole cell hand-over thing works at all mid-call at 80+mph so maybe they are not much of an issue unless the destination cell is already saturated at the time.
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#36Earlier quoted context omitted.
Faster travel meaning you are passing in and out of cells more often, and you are more likely to be passing through areas with bad coverage either for man-made geographical reasons (a steep embankment between you and most of the towers in range for instance) or because your route is more likely to take a straight-ish line that may pass through a pretty uninhabited area that is ether completely unserviced by the cell…
Trains also dampen the signal. Many German high speed trains have repeaters but those don't yet (hopefully!) work with UMTS. Cars and busses have admittedly the same problem but maybe to a lesser extent.
Cross Country trains (what was Virgin's bit of the rail franchises) are worse for this than anything else on the UK rail network. I'm told it is due to a combination of the materials in the construction of the carriage frame, and the anti-glare layer in the windows. If you are at the end of a carriage, signal strength/reliability seems to jump a bit when you are sat at a station and the doors are open.
Other trains don't seem nearly as bad. I'm not sure how much of that is due to different construction or (in the case of other modern(ish) rolling stock) anything like the repeaters you mention (though as all the franchise owners are cheap-arses I very much doubt that tech has been paid for by any of them!).
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#37Here's animation of the packets of a Facebook page hit over 3G on a moving bus:
http://vimeo.com/17248120
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#38We should probably get these long round-trip protocol issues ironed out before we build our galactic internet
Unsurprisingly, this is a well-known problem: http://ipnpr.jpl.nasa.gov/index.cfm
While I don't know that we can fairly say the Internet qua Internet has been extended past Earth (and associated environs), NASA certainly uses a Solar System-scale network already, and while they haven't made a big deal about some of the routing they've already done, if you read the press releases carefully they'll sometimes mention how they routed the signal from one probe through another. It's already a network.
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#39We should probably get these long round-trip protocol issues ironed out before we build our galactic internet
I would encourage you all to look at the site dtnrg.org It's for the DTN research group, which among other things is beginning to architect and implement the so-called Interplanetary Internet. Some early trials have been run among NASA, ESA, and JAXA mission-control centers, as well as one flight test on EPOXI (used to be the Deep Impact mission)
Re: Why mobile apps suck when you're mobile (TCP over 3G)
#40There were plenty of wireless-optimized TCP replacements proposed back in the days when WAP and XHTML Mobile were the hottest things around, but none took root as operators, web servers and browsers needed to adopt them in tandem. Now that smartphone apps are widespread and someone developing a service can control both sides of the connection, there's definitely room for someone to devise a really good TCP replacemen…
The article misses that this is fundamentally an issue with the PHY level of "mobile" broadband systems.
If you've got a very simple radio, say, a ham 2 meter handset, you find there are interference patterns caused by multipath interference that cause the signal to get stronger and weaker as you move half a wavelength this way or that way. This causes a fluttering noise when you're listening to somebody transmitting from a car.
A more advanced radio that uses a spread-spectrum signal finds that at any moment of time, some parts of the signal's frequency range is in-phase and some is out-of-phase.
If your goal is to make a low-bandwidth signal robust, you can spread a low-bandwidth signal over a wide spectral range and you won't notice fading. On the other hand, if you're trying to send as much data as you possibly can in the bandwidth you've got, you're ultimately going to implement something like OFDM. Now, in an OFDM system, you're using frequencies in parallel to transmit more data, not to improve robustness. If you're sitting in one place your system can figure out what the fading is and work around it. If you're moving, the relative performance of the subchannels is always changing too fast for OFDM to work.
This is how you can have a good voice connection on your phone (which is using a PHY truly built for mobile operation) but not have it on for data (which is using a PHY built for high performance operation from a fixed point.)