Apps and Desktops in the Cloud? How passé!

It’s time for space computing – or in this case desktops as a service in space. The news: NASA has adopted Citrix XenDesktop 4 to deliver virtual desktops as a service to astronauts, whether on the ground or in the International Space Station. It was this deployment that enabled the recent first tweet from space.

I must admit that when I first heard about this I wondered what all the fuss was about, at least from a technology perspective. Then I realized there might be a couple of challenges delivering a virtual desktop to space: bandwidth and end-to-end latency.

Transmission to and from the ISS uses the KuBand (which you may have previously encountered if you own a police radar detector). With KuBand, NASA can drive transmissions at high power, delivering greater fidelity, enabling smaller dish sizes, and transmission over greater distances. It also offers high bandwidth. So, there’s a good link layer. I could anticipate some challenges with TCP window sizes, but assuming the boffins at NASA had those under control, the session and presentation layers were easy: NASA uses Citrix Branch Repeater for WAN Optimization between the ground and space station, and Citrix HDX™ technology to deliver the virtual desktops, both of which do a great job of reducing resource requirements and enhancing the delivery of a remote “high def” desktop experience.

All told, I learned, NASA can deliver up to 3Mb/s to the ISS from earth, and up to 1 Mb/s from the ISS to earth – way more than you’d need for twitter, even if you were Chris Hoff. I imagined astronauts watching YouTube from the ISS on their XenDesktops…

The second challenge you’d expect is latency. Space is further away than the Cloud so a real WAN might be on the cards. I sat down to figure out the latency an astronaut might expect when working on a virtual desktop from the ISS:
The ISS is kept in Low Earth Orbit (LEO) between 278 km (173 mi) and 460 km (286 mi) altitude, and travels at an average speed of 27,724 km/h (17,227 mph), completing 15.7 orbits per day. So there would be absolutely no problem with delay then? Transmission over this distance is nearly instantaneous – less for example than the 1350 km between me and my XenDesktop in San Jose CA, as I type this blog.

Well, not quite: It turns out that latency is a very big deal to LEO communications not because of the vertical distance between a ground station and the ISS when it is directly overhead, but because of the need to encode, transmit, store and forward packets, and the disastrous effects of retransmission on throughput in a WAN. The enormous speed of the ISS leads to challenges because of the doppler effect, which requires a receiver to frequency shift as the ISS passes through the sky. Moreover the ISS remains visible for only 15-20 minutes per pass, before passing behind the earth. In the early days of the US Space Program they tracked satellite signals in sequence from each of a set of earth stations spaning the globe, relaying the signals back to the base station. Today communications from the LEO based ISS are relayed up to a set of geostationary satellites called TDRSS, which can continually track it.

The combination of significant latency (half a second to GEO and back) and the need to store and forward packets, led to an adaptation of TCP/IP to deal with the challenges of inter-planetary communications. The Delay Tolerant Networking concept (DTN) was initiated by Kevin Fall at Intel Research in 2002, and by now is capable of sustaining TCP/IP based communication with the ISS.

At the end of the day, the NASA folk tell me, there is about 1.5 seconds of latency from the ISS to earth and back. Though I’m sure I wouldn’t enjoy using XenDesktop with that latency, I now understand why we heard about the astronaut’s first tweet from space, rather than a video call via skype to his mum.