Qirong Ho, James Cipar, Henggang Cui, Seunghak Lee, Jin Kyu Kim, Phillip B. Gibbons, Garth A. Gibson, Greg Ganger, Eric Xing http://media.nips.cc/nipsbooks/nipspapers/paper_files/nips26/631.pdf
分散環境ではネットワークのレイテンシーが問題になってパラメータが返ってくるのが遅く、ネットワークがCommunication bottleneckになる。 例えばLDAなどをSynchronousな並列実装を行うと、計算時間の80%以上がネットワークに喰われる。 さらに、分散環境では各ワーカーが平等なパフォーマンスで動くとは限らないため、Synchronousな方法ではスケールさせることが出来ない。 理論サイドではシステムの問題を単純化しすぎてSynchronousなアルゴリズムの研究が多すぎたかもしれない。 一方、MapReduceやSpark、GraphLabなどシステムサイドではアルゴリズムの問題を軽視し過ぎているかもしれない。 例えば、Bulk Synchronous Parallelに従っていると、各サーバーが一様ではない問題を考えると難しい。 しかし、完全に非同期にしてしまうと、やはりワーカーの性能がばらついた時に計算結果の破棄が多くなり、また収束性が理論的に保証できない（もしくはしづらい？）問題がある。 なので、BSPと完全非同期の間にある解が求められる。 それがStale Synchronous Parallelである。 各ワーカー（スレッド）のIterationの回数をカウントして、速いワーカーと遅いワーカーの間のItration回数の差が定数Sを上回らないようにだけ待機する。 これによって、BSPと完全非同期の問題を両方解決することが出来る。
SSPがなぜ収束するかというと、シーケンシャルな実行の近似になっているからである。 途中で計算結果が捨てられる可能性があるが、その数がSでBoundされるので、Sを含む形で理論的に収束を証明することが出来る。
この仕組みはシステムとしてはParameter Serever（SSPTable）というものをMasterとして用意することで実現することが出来る。 各ワーカーの
LDAの実験で性能を確かめる。 BSPに比べると、StalenessパラメータSを増やしていけばネットワーク待ち時間を削減することが出来る。 対数尤度を評価したところSSPはBSPと完全非同期のどちらよりも早く上がっていって、収束していく挙動を示した。 ワーカーの数を増やしていくことでどんどん収束速度が早くなることも確認された。
Future workとしては自動チューニング、平均ケースのBoundなどが理論的にはある。 システムとしてはロードバランスやFault toleranceやConsistency保証などの仕組みが必要である。