It appears that this failure was not due to bandwidth itself, but to a burst in the sheer number of app-level phone-homes. NTT employs pretty sophisticated traffic classification and routing and my guess is that the actual number of "control channel" connections burst to a level that the hardware they'd allotted to handle these sorts of connections couldn't deal with, resulting in some cascading failures. And for some reason, they don't want to (or can't) go all elastic for this type of traffic.
It also sounds like what they want Google to do is to have app developers route through so that connections pool into a single thread? They don't mention c2dm at all, but seems like forcing c2dm would help (though it would leave Android =<2.1 users in the cold)?
Comments
It appears that this failure was not due to bandwidth itself, but to a burst in the sheer number of app-level phone-homes. NTT employs pretty sophisticated traffic classification and routing and my guess is that the actual number of "control channel" connections burst to a level that the hardware they'd allotted to handle these sorts of connections couldn't deal with, resulting in some cascading failures. And for some reason, they don't want to (or can't) go all elastic for this type of traffic.
Here's some background:
http://itpro.nikkeibp.co.jp/article/NEWS/20120127/379582/
It's in Japanese, but the Google Translation gives way more info than the TNW and Reuters articles: http://translate.google.com/translate?sl=ja&tl=en&js...)
It also sounds like what they want Google to do is to have app developers route through so that connections pool into a single thread? They don't mention c2dm at all, but seems like forcing c2dm would help (though it would leave Android =<2.1 users in the cold)?