

Why mobile apps suck when you're mobile (TCP over 3G) - dps
http://blog.davidsingleton.org/mobiletcp

======
kalleboo
There 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 replacement (layered on top of UDP) with an iOS
library, an Android library, and an Apache mod.

~~~
dps
I think this is a _really_ good idea. Startup? PhD thesis?

~~~
jarek
Do tell how you reckon a start-up could bring to popularity, let alone
monetize a new Internet protocol?

~~~
goof
We're not talking about replacing TCP as the standard transport protocol. But
if you're a mobile app developer and you control both the client (via a native
app) and the server you can use whatever you want. If someone provided client
and server implementations of a more efficient networking protocol it could
become popular.

I have no idea about monetization though. I doubt just charging for the code
would work.

------
dspillett
The problem for those of us on capped and/or expensive-per-kbyte mobile
connections (in the UK that is everyone who doesn't spend a large chunk on
their monthly contract - people on Virgin pay-as-you-go pat £3 for a day's
access but IIRC you get cut off after 25Mbytes in that day) with restarting
connections early is that the ~20 seconds worth of packets queued up during
the blip is going to be sent anyway even though they are now no longer needed.
20 seconds worth of discarded packets could be quite a bit if you were
transferring data at decent 3G+ speeds just before the blip.

------
jchrisa
This is exactly what CouchDB, and Mobile Couchbase for Android and iOS, is
designed to fix.

Networks are slow. Mobile networks are slower. The most robust fix to the
problem is to "optimistically replicate" your application data to the end
user's device, so that the network latency does not become part of the user
experience.

This is a strong fit for applications like CRM or geographically constrained
apps, as the data sets are small enough to fit completely on your devices. For
larger data sets the issue becomes: which subset of the data should be copied
to the device ahead of time.

The user should never needs to wait on the network. All data operations are
played against the local Couch, which handles asynchronously transmitting
changes to and from the remote server, in the background. This pattern makes
it much easier for app developers to make responsive applications, where users
are never left waiting on multi-second round trip times.

------
aristus
Here's animation of the packets of a Facebook page hit over 3G on a moving
bus: <http://vimeo.com/17248120>

------
rowanseymour
Very interesting and sheds some light on the weird latency issues I see here
in Rwanda, where 3G issues aren't limited to being on moving trains. Sometimes
pinging shows crazy return times of 30000-60000ms. Other times they're only
200-400ms but every other ping packet times out, i.e. one packet through, next
one drops, and so on. Still trying to figure out exactly what's happening
then.

~~~
jchrisa
Bufferbloat means when you refuse to drop packets, you get longer latencies:
<http://www.bufferbloat.net/>

Why you'd have big buffers sometimes and not others, I have no idea.

------
praptak
It looks like this should be (at least partially) dealt with at the OS level
especially if the OS in question is a mobile one.

------
sebandr
I'm in a start up that's developed techniques using UDP to allow someone to
roam across wifi - in other words we have managed to reduce the tcp delays and
time outs to provide consistent and reliable handoffs between wifi zones and
devices - regardless what of the network provider. The technology also allows
hot handover between femto and wifi too. Right now we're mostly focused on a
mobile app to improve broadband delivery of content to mobile users in
shopping malls, commercial zones, etc. but that's low hanging fruit.
Eventually we believe that this can be integrated in mobile apps to let others
us this for true mobility while running broadband services.

------
schiptsov
The much worse problem is DNS. For big networks that pushes always the same
two IPs (even without round-robin) it is a disaster. There are lags of
servers, lags of network, dropped packets, useless overhead with EDNS and
different packet sizes (timeouts and retransmitions) and above all, the
practice by content providers and CDNs to use hundreds of changing in real
time hostnames to implement load balancing and/or geoIP based assets loading.
They use near zero TTLs which makes caching useless and dynamic sets.

Indian Airtel's network is a live example of that disaster. It is almost
unusable, while they still actively promoting 3G and iPhones. ^_^

------
justincormack
Interesting, suggests a quick fix might be for the client to not use
keepalive, or to selectively close connections that are very slow so as to
start new ones. Potentially a much easier solution than writing a new
transport.

------
lukego
Don't worry, our Lisp startup (www.teclo.net) is fixing TCP over mobile
networks, it will all be fine soon enough. :-)

~~~
etherealG
perhaps you could explain a bit more about how you're solving the issue?

~~~
jsnell
As noted elsewhere in this thread, the properties of wireless networks
conflict badly with the design principles of TCP. We have a custom TCP stack
that replaces some of the standard TCP algorithms with new ones carefully
tuned for mobile broadband. It can act as a transparent proxy, presenting a
standard stack towards the internet and a optimized one towards the radio
network. The packet stream is still standard TCP though, so no client changes
are needed.

The product is deployed in some >10Gbps networks, and shows very impressive
gains for real live traffic.

~~~
etherealG
thanks for the explanation :) does your layer only sit between the mobile and
the point at which the network becomes a wired connection? like, just the
other side of the cell towers?

~~~
jsnell
No, it'd be somewhere in the core network. Ideally next to the GGSN.

------
micheljansen
Interesting. I cannot stop thinking how cool it would be if Google actually
decides to step in and propose an alternative protocol for mobile networks. If
they put it in Android, they already have a huge base for adoption.

Ended up writing a piece on Google because of this on my blog:
<http://micheljansen.org/blog/entry/1060>

(shameless plug :P)

------
kaeso
As an historical note, most of these concerns are the same expressed in RFC
3481 (category: BCP). You'll note from there that some of the issues are still
open even if almost a decade has passed.

------
warfangle
Would Vint Cerf's recent work on a high-latency network standard for space[0]
apply? Would it make mobile more useful? It's designed for latencies of days
(not seconds), so it might be overkill. But something to masticate upon...

0\. <http://www.technologyreview.com/communications/21601/?a=f>

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

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

~~~
wibblenut
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).

------
dps
Dave Taht points out <http://www.bufferbloat.net/> which looks very
interesting!

------
hxf148
Mobile HTML5 apps, the future is the past. :) Check ours out
<http://infostripe.net>

------
jb55
We should probably get these long round-trip protocol issues ironed out before
we build our galactic internet

~~~
merijnv
TCP is already out as a protocol for our galactic internet, see relevant
comment from Linux TCP implementation:

    
    
        /*
         * [...] Note that 120 sec is defined in the protocol as the maximum
         * possible RTT.  I guess we'll have to use something other than TCP
         * to talk to the University of Mars.
         * PAWS allows us longer timeouts and large windows, so once implemented
         * ftp to mars will work nicely.
         */

~~~
mooism2
I sincerely hope ftp is a distant memory by the time the University of Mars
opens.

~~~
cpeterso
well, why not? Martian students will need to use _something_ to transfer
files. Perhaps SFTP?

The International Space Station still uses Kermit! At least they did in 2003:

<http://www.spacedaily.com/news/iss-03zq.html>

------
willyt
Is there any way round this for HTML5 apps? I know you can save an app icon on
iphone but when you launch it just launches safari which seems to make a
network request to check if the site is up to date? (Sorry, I'm a bit naive
about all this HTML5 stuff.) e.g. Gmail in safari on iphone is useless when
you get long latency situations like this. Is there a way round that?

------
etherealG
anyone know what tool I could use to run a similar test?

------
zobzu
SCTP anyone?

------
clistctrl
Not that his advice is bad, but these statistics are a bit biased. Trains make
for some pretty unusually difficult channel conditions.

~~~
mooism2
Trains moreso than cars/buses? Why?

~~~
dspillett
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 network or where the only tower(s) in
range are some distance away. Also if you are travelling by bus (and to a
certain extent by car) you are more likely travelling a shorter distance than
if travelling by train so are less likely to be passing through areas that are
badly served because there is no money in the networks serving the two local
farmers as well as they serve a small town.

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

~~~
dspillett
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!).

