A new approach to mobile Internet protocols could improve the usability and reliability of mobile applications.
At the annual Usenix tech conference last month in Boston, two MIT researchers formally unveiled a new protocol, and a remote log-in program using it, that was specifically designed for mobile clients and the intermittent, low-bandwidth connections that typify today's wireless networks. The program, dubbed Mosh for "mobile shell," is intended as an alternative to the venerable Secure Shell (SSH), long used to create a secure connection between a client and server computer, for remote log-in, command execution and other services.
IN THE NEWS: Quick look: The Higgs boson phenomenon
In advance of the paper, Mosh and the new State Synchronization Protocol (SSP) were made available for free, currently on GNU/Linux, FreeBSD and OS X, via an MIT website in April. The Usenix technical presentation is available on the Mosh site or on YouTube.
So far, it's been downloaded more than 70,000 times. Judging from a catalog of tweets, users are ecstatic:
"If you use SSH often, you want to look at mosh.mit.edu - After 48 hours (mails/irc/jabber are all remote for me) I can say it rocks!" -- @paulrouget "mosh (mosh.mit.edu) is awesome. Tested it for two weeks and it really made my life easier: faster feedback and no more reconnects(!)" -- @esmolanka "Using mosh on the train rather than plain ssh, and it does actually make a huge difference! Very usable interactive ssh sessions at 160KM/h!" -- @andyd
SSH traditionally connects one computer to another through their text terminals over TCP, says Keith Winstein, a graduate student with MIT's Computer Science and Artificial Intelligence Lab (CSAIL), and Mosh's lead developer. SSH is often used by network and systems administrators for remotely logging into servers. But versions of it are also included with Microsoft Windows, OS X and Linux. It's the reliance on TCP that creates headaches for mobile users.
TCP assumes that the two endpoints are fixed; and between them, bytes must be received in exactly the same order that they are sent. That's the "worst possible" approach for mobility, says Hari Balakrishnan, a computer science professor at CSAIL and co-author with Winstein of the Usenix paper.
"This is not a great way to do real-time communications," says Winstein. If there's an outage, TCP tries to make sure that you get all the bytes in order: and it keeps trying. But in real-time communications, such as videoconferencing, a chat session or your current location, what you want is the most recent information -- the latest video image or your current location on a map, for example -- not all the information you may have missed since the outage.
"If there's an outage for five seconds, you don't want to wait five seconds and have to see what you missed," Winstein says. "You just want it to start up again [where you are now]."
TCP's underlying assumptions mean that it can't handle roaming or intermittent connections. If you're running SSH at home to your company office, close your laptop, drive to headquarters and plug in to the company LAN, your SSH session is lost. Similarly, if you roam between Wi-Fi networks, or between Wi-Fi and cellular networks, you lose the SSH link.
Another problematic behavior is the wireless network delays on echoing the keystrokes in an SSH session. Winstein told his Usenix audience that "we've measured delays of 40 seconds over Verizon's LTE network." In his Usenix demo, Winstein showed SSH keystrokes over a cellular link bogging down as the network added delays between the user's keystrokes and the actual appearance of the character on the computer screen. That's because the keystroke is sent from the client to the server application, where it's interpreted and then sent back to the client for display. For example, the "N" key in an email program might call up the "Next" email.
The State Synchronization Protocol and Mosh were designed to fix these problems.
Instead of running over TCP as the transport, for example, SSP relies on the User Datagram Protocol, a connectionless, stateless transport well-suited for a range of real-time communications.
In addition, SSP uses a different connection naming method. Traditionally, says Winstein, Internet connections are based on fixed IP addresses and port numbers, and it assumes the addresses don't change. "By definition, if you switch the IP address, you lose the connection," he says. In mobile networking, "the IP address always changes," Winstein says. Similarly, if the wireless network disappears, or a laptop goes to sleep for three hours, the connection breaks.
By contrast, SSP uses cryptographic credentials, not an IP address, to identify the two endpoints. "You name your connection in a 'network-independent' way," says Balakrishnan. The crypto protection also prevents the connection from being hijacked by an attacker.
Finally, instead of trying to synchronize ordered sequences of bytes, SSP synchronizes "objects" -- in the case of Mosh, the object is a text terminal -- and their states. The objects support a simple API so that SSP can query them for information about their respective states, and then figure out what information to send to the client in order to bring it "up to speed" with the current state.
"Traditionally, there's very little information shared between the applications and the protocols that they use," says Balakrishnan. "An application writes data into a TCP socket and forgets about it. SSP makes the application more aware of what's being sent. The application and the protocol are able to come up with a common vocabulary to name pieces of data. When network conditions change, the application using SSP remains in control and SSP enables the resynchronization."
This results in a dramatic change in behavior, as the tweets by Mosh users illustrate. Winstein likens it to the change-of-address process that magazine subscribers used to go through: In effect, SSP tells the network that "Keith" has moved to a new location, is still really Keith, and to keep sending him data.
Mosh uses an algorithm to predict keystrokes, with great accuracy according to the researchers. The predicted characters are displayed underlined, until the server confirms them. Winstein's Usenix demo showed a very fluid Mosh typing experience, resembling the kind of interactivity and responsiveness that one associates with a PC-based word processor.
Mosh is currently the only application that makes use of SSP, and Winstein readily admits that SSP is "not fully baked for full application development." But he foresees widespread uses for it. "Applications like G|chat, Gmail and Skype could all benefit from these techniques," says Winstein.
He has the perfect example: on Feb. 6, Winstein was using his Google Androidsmartphone to send a Gmail message to someone, as he was leaving his MIT office. The phone switched from a Wi-Fi to a cellular network, and did so smoothly.
But Gmail hung up: Five months later, it's still trying to send that same email.
