The need for speed: connecting faster

Speed. However fast something is, we want it faster. Faster just seems better, it’s a clear winner, patience is now measured in hundred’s of a second on the Internet. IM/Chat is really nothing more than really fast email, you know when you hit the return key, your recipient gets your message immediately. Icon blinks, window opens, message appears. It’s fast.

Think about a phone call, it’s a conscience effort, find the number, dial or click the number, mobile network energizes, radio channels get allocated, a million things happen transparently as I fumble not to drop my £6 pint on the floor. It used to seem like it was quick; a couple of seconds; but now it seems pokey.

Video connections are usually a bit more formal. A pre-scheduled call. Things have to be set-up in advance (check your hair, check your look and yes you do look stupid). You click, download, agree, wait, re-wait and wait some more.

WebRTC promises to reduce this time set-up interval. Yet as I click the already pesky ALLOW button, deep inside of me a timer starts. How long is thing going to take? However long it is or isn’t, I want it faster and I want it now. WebRTC technology has barely made it out of the gates and I’m already lamenting that it’s too slow.

I’m not alone. Trickle ICE which is short hand for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol. I’m sure you, like me, fully grasped this concept from the title alone.  It’s an IETF draft for the moment, but the authors are worth mentioning – Google, Mozilla and Jitsi (the lead author) who is a long time contributor to SIP/XMPP /Jabber standards. You know, credible names.  Like all IETF drafts, this document can live, expand, change or simply disappear.

Perhaps the abstract is a bit more descriptive:

This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists.  With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete.

Clearer? No (just remember the authors talk like this in person as well).

What Google & Mozilla are already on the hunt for it how to enable WebRTC sessions to connect faster, start doing things earlier and skip steps where feasible. For a one hour video call, a couple of minute set-up is fine, for a 3 minute phone call, a few seconds, but what if I want to have a 30 second conversation, I’m gonna want connections times in hundreds of a second. I’m not going to be happy until I can have a Star Trek moment.

The good news, the industry sleuths on are on the case, a solution is out there, it will all get better.