& cplSiteName &

Google: Resistance Is Futile...

Light Reading
News Analysis
Light Reading

Internet IM/VOIP services offered by Skype Ltd. and MSN Messenger have millions of users, but can't talk to one another. Google (Nasdaq: GOOG), however, says its Google Talk product is built on the sort of open standard that will eventually “federate” all the instant messenger and VOIP clients out there.

Google Talk product manager Mike Jazayeri likens the situation to the early days of email, when only people using the same client could email one another. Eventually they all adopted one open standard allowing all clients to interoperate.

For Internet-based VOIP, Google believes its XMPP -- also known as Jabber -- is that standard. “We said we were going to use an open standard from day one,” Jazayeri says. Other IM clients such as Apple Inc. (Nasdaq: AAPL)'s iChat and Cerulean Studios' Trillian also are underpinned by the XMPP standard. (See Google Jabbers On.)

When email federation happened, usage of email exploded. Usage of wireless text messaging also grew exponentially after the wireless service providers adopted the common SMS standard enabling, for example, a Cingular Wireless customer to send messages to a Sprint Wireless (NYSE: PCS) customer.

“We think it's inevitable that IM starts using an open standard,” Jazayeri says. If and when that happens, and if history is any guide, the spike in usage could take away still more call minutes from the wireline, wireless, and VOIP services of traditional voice providers.

The movement of IM/VOIP clients onto wireless devices also may help bump up usage. Jazayeri points out that Nokia Corp. (NYSE: NOK), Sony Corp. (NYSE: SNE), and BlackBerry (Blackberry) have built Google Talk into their wireless devices, effectively freeing the IM/voice service from the PC desktop. (See Nokia Adds Google Talk.) Of course Google isn't the only IM/voice provider claiming to use an "open" standard -- Yahoo Inc. (Nasdaq: YHOO) and Microsoft Corp. (Nasdaq: MSFT) make similar claims. Jazayeri argues that Google Talk’s XMPP is the only IM standard that’s been approved by a real industry body, the Internet Engineering Task Force (IETF) . (See Jabber Jingles All the Way.)

“Microsoft will tell you that their client is SIP compliant, but what they mean is that in their enterprise product they support SIP, but not their consumer product,” Jazayeri says.

Yahoo’s senior director of voice product management Jeff Bonforte told Light Reading some months ago that he is reluctant to open his service to others, for security reasons. VOIP has its own flavor of spam, called “SPIM,” and Bonforte says he doesn’t want to subject his users to the abuses of unscrupulous users from other services. SPIM can arrive as a junk IM or as a recorded or live voice call from somebody somewhere selling something. (See Yahoo Launches VOIP Service.)

Jazayeri isn’t having it. “It’s a smokescreen,” he says of Bonforte’s reasoning. Jazayeri says SPIM filtering technology has advanced to a point where the vast majority of the stuff is blocked. Google Talk users have control over their buddy lists, he explains, and the client won’t take IMs or calls from strangers. “That has resulted in zero SPIM on our network,” Jazayeri says.

While some competing IM companies allow their software clients to interoperate, most are closed to outsiders. Microsoft’s MSN Messenger struck a federation agreement with Yahoo’s Messenger product last October and, the companies say, it created the largest IM community in the world with around 275 million users. (See MSN, Yahoo Link IM Services.)

eBay Inc. (Nasdaq: EBAY)'s Skype service remains closed, but a recent advertising agreement between Google and eBay could lead to a peering arrangement with Google Talk users. Jazayeri says such an interconnection would allow the exchange of IMs between the two services, but not necessarily voice. (See Google, EBay Team .)

Whether or not a given service is open depends a lot on when it entered the market. “You can look back at history and see that people who came in early went to the walled garden approach -- email was almost entirely walled garden in its early days,” Jazayeri says. Services that picked up a large user base early on tend to wall their users in, he contends, while later entrants have less to lose and more to gain by federating.

Regardless, as services begin to catch on, Jazayeri says, the “walled garden” players are eventually moved by consumer demand to open their services to others. Players that don’t “will have a very difficult time."

— Mark Sullivan, Reporter, Light Reading

(12)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 2 / 2
mr zippy
mr zippy,
User Rank: Light Beer
12/5/2012 | 3:39:13 AM
re: Google: Resistance Is Futile...
"SIP/SIMPLE-based IM is not necessarily any better than XMPP; it's just a different protocol, but in reality it operates in much the same way."

The model is supposed to be that the SIP signalling messages may (but not must) go through server infrastructure, with the fundamental objective of converting that SIP address into a current IP address for the end-point. Once that is resolved, the media streams are intended to go direct between the end-points. Swap media streams for IM session, and that's the model that I think XMPP should follow. So, as somebody else said, the architecture tends to be hybrid, with the least amount of "client server", and client server being constrained to short lived transactions - the call signalling, rather than the actual voice data. Short lived transactions are fare less vulnerable to or impacted by server failure, and even then that can be designed around - DNS is a good example of how to do it.

Although people need to or tend to put in servers for SIP e.g. for NAT traversal, or Media Gateways, they tend to be closer to the "clients". The observation is that the closer to the clients the server is, the less scaling problems you have, and the less impact a server failure will have to a number of clients. The further away from the clients the server is (e.g. somewhere on the Internet, verses somewhere on your own network), which usually means more clients will connect to it, the harder (or more expensive) it is to increase performance (or scale it), and the harder it is to provide availability.

When I suffered a remote server failure while using Jabber, yet I knew that the person I was communicating with was still likely to be available via IP (we resorted to email to work out what happened, and could perform traceroutes to each other), the way to solve it that popped into my head was "I'll just run a jabber server" on my PC, and have him connect to that. He could have done the same. Of course, then I'm running both a Jabber client and Jabber server, which makes it a peer in the IM network - it both provides and receives services.

The only reason not to run a server on my PC, restricted to my own IM sessions, is if I didn't have the computing or bandwidth resources to do so. My PC sits at probably an average of 99% idle over a day, and the bandwidth consumed would be very minimal - this is text primarily after all. The only increase in resource consumption is going to occur when I'm sitting in front of my PC using IM. I have an excess of resources that I could run a server with (Remember, this server would be constrained to only being used by people I talk to, and there's only so many concurrent IM sessions my brain can handle - probably no more than about 5 to 7).

So maybe that's the rule. If running a "server" on the "client" is possible, and doing so will more easily allow increases in performance, provide better application scalability and provide increased availability by locallising the impact of a failure to only the peers using that failed peer, then the architecture of the application shouldn't be client/server, it should be peer-to-peer.
mr zippy
mr zippy,
User Rank: Light Beer
12/5/2012 | 3:39:12 AM
re: Google: Resistance Is Futile...
"The one problem I see with peer-to-peer is who-ya-gonna-call when it doesn't work? If there is no central point of control, then there is no one responsible for making sure the service works. It's usually not a problem for the tech savvy, but could be a major problem for the average computer user."

I don't see how the behind the scenes architecture of the application has any effect on the user of the application. Whether it is client/server or peer-to-peer, all an average computer use cares about is is the person I want to talk to available, and can I start and continue a session with them. That's easier to achieve and more likely to happen in a peer-to-peer model, as the resources required are spread out or distributed and closer to the end points. The resource "path" requirements for the session are also more direct between the peer-to-peer end-points.

As an example, imagine I'm going to use Google's XMPP service. The "ulimate" in client server would be for them to run all their servers in one of their facilities somewhere in the US. Well, I live in Australia, so if Australia somehow gets cut off from the world, then I'm stuck, even though I'm still in a country with available Internet connectivity for all 20 Million or so of us, so there's still plenty of people I can talk to. I'd be better to choose a XMPP provider who's located in Australia. Then again, what if my city becomes cut off from the rest of the world, there's still people in my city I talk to - probably more than anywhere else in the country or world. Maybe I need to find a local XMPP provider in my City. Hmm, that's also vulnerable if my suburb gets cut off. Maybe, if I want the job done properly, I should do it myself, so that my IM capability fails only if the two end-points that would be involved failed, or if there was no IP path between them.

Regarding control and responsibility, there are two things that dictate that. Who owns it, or who's paid because they own it.

I own my PC, so I have to assume responsibility for making sure it's running. My IM session partner's would have the same responsibilty. If they're having trouble with their, I may be able to help them fix those problems if they can't - it's in my interests to do so if I want to talk to them.

I don't own my ISPs network, but I pay them to make it available - to keep it running - which includes making sure their upstream providers also provide availability. If my ISP doesn't provide availabilty, I'll find a different one that does.
<<   <   Page 2 / 2
Featured Video
Flash Poll
Upcoming Live Events
September 17-19, 2019, Dallas, Texas
October 1-2, 2019, New Orleans, Louisiana
October 10, 2019, New York, New York
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
December 3, 2019, New York, New York
December 3-5, 2019, Vienna, Austria
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events