Hacker News Reader

Comment by kalleboo | Hacker News Reader

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.

View on HN

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

I probably missed half of what you were trying to explain there, but I didn't see a good solution. Are you suggesting we should give up speed for reliability at the PHY level?

It's a choice made at the PHY level and it's a tradeoff that's a little more complex than speed vs. reliability -- mobile operation introduces special challenges, as well as operation with weak signals (satellite), as well as operation in urban areas. There's a reason why Europe has 3 distinctly different digital television standards.

For TCP over 3G, could they just turn off reliability at the PHY level and let TCP do its thing?

I don't think you understood the article. It is not about the physical restrictions and trade-offs of mobile broadband. It is about the inefficiency of TCP on such connections. Current TCP implementations are optimized for wired networks which usually have fixed bandwidth and latency. They use dropped packages for congestion avoidance, interpreting package loss as a signal to slow down transmission.

Wireless networks with their higher packet loss (compared to wired ones) fool the sender into believing that the connection is satured. Combine this with the enormous buffer sizes used by mobile broadband systems and the TCP congestion control algorithm throttles the connection to an unusably slow level.

The author is not making a case for trading speed for reliability by using a different PHY, he is making a point for embracing the package loss and delays that exist in current mobile broadband systems and using those characteristics to create a smarter transport layer protocol to replace TCP on mobile devices.

Yes, I do recognize that.

In the big picture, however, it's generally better to fix the part of a system that's broken (the PHY) than it is to try to compensate for the underlying problem in upper layers.

It's also good to be careful about your terms. "Mobile" means operation out of a car or other motorized moving platform. "Portable" means a device that's being carried by a pedestrian. When the bandwidth of a radio channel gets wide, these become very different environments.

All I can say about new protocols is that you can go to your local Uni and find (quite literally) a ton of conference proceedings on this very topic. It seems that somebody has been funding a ludicrous amount of research on TCP replacements for decades without anything practical coming out of it.

Out of all that literature you ought to be able to find something that works or find a good reason why it can't be done.

Mobile also means "As in it's carried around as well as used in cars". It's a term for smartphone. They're using modern parlance to talk about smartphones, not radio parlance.

Yeah, but you don't need to do much to TCP to make it work perfectly well on wireless.

Let me repeat that: Don't fuck with TCP. TCP is fine. It's BUILT to deal with your lousy network, it's DESIGNED to deal with nuclear attacks from the Guys of the Bad Color, and (ironically) the worst thing you can do to TCP is to try to be nice to it.

"What about keep-alives?"

There are no keep-alives in TCP. If two hosts are in agreement about the address and port, they can keep a connection in an open state until the universe goes cold. (There may be keepalives necessary /above/ TCP, but TCP itself doesn't use 'em). Don't yammer something about your internal state every 30 seconds; you don't do it on the bus home, so don't do it on your network, either.

"Don't we need this proprietary fancy-schmancy buffering algorithm from FuppedUck Communications Consultants? They keep telling us we're toast without it."

No. Just run TCP. Spend money on decent routers.

"I'm feeling really nervous and I want to, like, disable Nagle for everything. Isn't that what you do? Turn Nagle off and maybe muck with the --"

You're from AT&T, aren't you?

Not entirely true. TCP is certainly decent, but it's not designed to deal with networks where the delays are extremely transient and the capacity is variable. It's not designed for heavy buffering. And so on.

It can be fixed with congestion control protocols tacked on the side, I think, but it's designed for wired networking with slow transients in the performance profile.

It IS, however, better than anything that I'd be able to hack together quickly.

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 directly instead of sending TCP packets. (not entirely unlike the sshuttle VPN).

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.

TCP is end to end. 3G is just carries data to your service provider. So wouldn't faking TCP screw up the communication between the mobile service provider and the server you're communicating with?

I think this is a really good idea. Startup? PhD thesis?

Here is a paper from 03: http://www.usenix.org/event/mobisys03/tech/full_papers/chakr...

As I recall, one of the key problems this group found was that GPRS had a very low incidence of packet loss. This was because the physical layer protocol had some error correction built in. TCP wasn't designed for this and ended up doing the wrong thing. This group proposed a custom reliable protocol between the mobile device and a proxy gateway, and their results showed improved performance.

We're not talking about GPRS but I am curious why there is so much packet loss?

Also, just FYI: MobiSys (the top academic conference on mobile systems) is happening in the DC area this week.

I'll bet you thought Vint Cerf was just a trophy hiring. :) http://gigaom.com/2009/11/06/vint-cerf-plugs-his-plucky-spac...

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

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.

I know of at least one company that tried this and failed. It was quite a long time ago and targeted large companies, but it did work. To give you an idea of how long ago, it was written for PocketPC 3.0.

The company is now defunct.

we did this at Visto corp a few years back. we wrote our own UDP based protocol that acknowledged every packet. it worked really well in horrible network conditions and was incredibly slow everywhere else. roughly speaking it was a bit like "TCP with no sliding window" and we had trouble w/proxies in the carrier networks. this was pre-3G.

SPDY or SCTP maybe? I'm not sure if they work better specifically in high latency environments, but they are touted as TCP replacements.

SPDY isn't a tcp replacement, it's a layer 7 protocol on top of TCP.

Actually, SPDY is an application layer protocol -- as HTTP -- not an transport layer protocol like TCP.

Reply on news.ycombinator.com