Skype's mega-FAIL: exec cops to cause
Live by P2P, die by P2P
Chastened by its pre-Christmas mega-FAIL, Skype on Wednesday explained in detail why the titanic titsup takedown happened and how the company plans to ensure that the globe will never again go VoIP-less for an extended period of time.
For those of you tuning in late, last Wednesday the online telephony service began to wobble, and soon crashed to its knees.
Skype engineers forsook their last-minute holiday shopping to frantically resuscitate the service, and by Christmas Eve they managed hoist it back on its feet, ensuring that little Billie in Blackpool could thank Gramps in Great Neck for that new Xbox Kinect controller come Christmas morn.
Now that normalcy has been restored, Skype CIO Lars Rabbe has offered his own detailed explanation of what caused the massive snafu.
Simply put, Skype was a victim of the network architecture that it has boasted – deservedly so – to be the reason for its advantages over other VoIP schemes: peer-to-peer workload dispersal.
Skype is built on Global Index technology, which is essentially a tiered P2P configuration in which some nodes are designated as "supernodes" that handle much of the directory functions that in a non-P2P network would be handled by centralized servers.
All well and good, but if those supernodes fall ill, all hell can break loose – which is what happened to Skype last week.
As described by Rabbe, the cascade of calamity that snuffed Skype was as follows:
- On Wednesday, some servers responsible for offline instant-messaging became overloaded, which caused them to send delayed responses to some Skype clients.
- Some of those clients were running Skype for Windows version 5.0.0.152, which has a bug that caused it to crash when delayed messages weren't "properly processed," to use Rabbe's words.
- Fifty per cent of global Skype users were running 5.0.0.152. Forty per cent of those crashed. Twenty-five to thirty per cent of those were operating as supernodes.
- Oops.
- The failure of those supernodes increased the load on the remaining supernodes, whether they were running 5.0.0.152 or not.
And now we'll let Rabbe take over the explanation:
While we expect this kind of [load increase on supernodes] in the instance of a failure, a significant proportion of users were also restarting crashed Windows clients at this time. This massively increased the load as they reconnected to the peer-to-peer cloud...Supernodes have a built in mechanism to protect themselves and to avoid adverse impact on the systems hosting them when operational parameters do not fall into expected ranges. We believe that increased load in supernode traffic led to some of these parameters exceeding normal limits, and as a result, more supernodes started to shut down. This further increased the load on remaining supernodes and caused a positive feedback loop, which led to the near complete failures that occurred a few hours after the triggering event.
Simply put, the worse thing got, the worse things got, until Skype was mortally wounded.
To stanch the haemorrhage, Skype engineers then created what they call "mega-supernodes" – higher-capacity supernodes – and flung them into the P2P cloud in the hope that their beefier capabilities could alleviate the load on the ailing supernodes and thus allow them to recover.
By Wednesday night it was apparent that the hundreds of mega-supernodes weren't getting the job done. And so, as Rabbe says: "...our team introduced several thousand more mega-supernodes through the night. During Wednesday night, full recovery of the P2P network was underway and the majority of users were able to connect to the P2P network normally by early morning (California-PST) on December 23rd."
Throughout that day and into the next the network stabilized, and Group Video Calling, which had been taken offline in order to lessen the overall load, was restored.
On Friday – Christmas Eve – "...we withdrew a significant proportion of the mega-supernodes from service, leaving some in operation to ensure stability of the P2P network over Christmas and New Year."
And here we are today, happily VoIPing again – until the next global P2P muck-up.
But Rabbe et al. are determined to not go through this holiday panic a second time. In his blog post, he lists a number of steps Skype will take to gaurd against a future global meltdown.
Seeing as how the failure was a direct result of a bug in Skype for Windows version 5.0.0.152, the first item on Rabbe's list of fixes is screamingly obvious: "We will continue to examine our software for potential issues, and provide 'hotfixes' where appropriate, for download or automatic delivery to our users.
"We will also be reviewing our processes for providing 'automatic' updates to our users so that we can help keep everyone on the latest Skype software."
A system for staged, universal, automatic updates would run the risk of globally disseminating a flawed upgrade, but that might be preferrable to the situation in which Skype found itself last Wednesday, when a bug in 50 per cent of its clients garroted its entire network. ®
COMMENTS
@Ominoshiko
I'm sorry, but this is a pretty poor idea. Bugs tend to persist across multiple versions until they are fixed. A bug like this which doesn't crop up until a particular failure mode triggers it (delayed messages in this case) might lie dormant for years, meaning it is remarkably easy to have the bug exist in 2 or more of the versions you have in the wild. Not being able to rapidly upgrade the software you have there means you can't fix major bugs quickly because people don't upgrade quickly. If you follow this methodology you end up with half the Internet running a bugged, security disaster like IE6!
The obvious "right thing to do"TM is pretty simple. The Skype Client and Skype Server should be separate processes on every machine. The server should do very little other than talk to the P2P network and pass messages on to the client. The client can parse all the messages and do the stuff that will likely crash. Hopefully over time the server becomes very stable and is rarely updated and hence likely to have very few bugs; the client becomes the thing you keep changing as new features come on line.
You're all missing the point
Rik actually wrote "normalcy"!
For this he should be locked in El Reg's darkest cupboard for a week.
You're clearly not an engineer
As if you were you'd realise that fixes don't happen instantly. First they had to identify the problem, then they had to create a solution (possibly going down a few blind alleys before hitting on a working solution), then they had to come up with a method to implement that solution on a scale large enough to alleviate the problem, they then had to actually go and implement that method, then once they had found it to work they had to monitor the situation and tweak their method as necessary.
If you're not impressed that they did that in the time that they managed to do it in (can't be bothered to go and check the article again, you say 12+ hours, if that's correct then I think that's a miracle on par with turning water into wine, but then I live in the *real* world) then you are clearly not, and have never been, an engineer.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Enabling efficient data center monitoring
Agentless Backup is Not a Myth
Top 10 SIEM Implementer’s Checklist
