Talk on Spotify: Large Scale, Low Latency, P2P Music-on-Demand Streaming

Editor's Notes

• #6: Video on-demand vs. Music on-demand: Differences #user behavior, #the size of streaming objects, and #the number of objects offered for streaming File sharing vs. music on-demand: similarities locating peers e.g. BitTorrent, Gnutella On Demand vs. Live streaming Client/ Server: Napster, Rhapsody, and We7 P2P: Joost, PPLive, and PPStream Structured: tree-based, and mesh-based PPLive: overlay structure, low latency tech
• #9: Simple Design: Reasons: Stutters Upload all or nothing
• #10: TCP instead UDP 1) Simplifies protocol design and implementation 2) TCP is nice to the network in that TCP’s congestion control is friendly to itself (and thus other applications using TCP), and the explicit connection signaling helps stateful firewalls 3) As streamed material is shared in the peer-to-peer network, the re-sending of lost packets is useful to the application
• #11: Simulations using data on cache sizes and playback logs indicate that, as caches are large, the choice of cache eviction policy does not have a large effect on cache efficiency
• #13: RFC 5681 [11] states that an implementation should reduce its congestion window if it has not sent data in an interval exceeding the retransmission timeout. Linux kernels can be configured to disable that reduction, and when Spotify did so the average playback latency decreased by approximately 50 ms. We remark that this was purely a server-side configuration change
• #18: Prefetching: If clients begin prefetching too late the prefetching may not be sufficient to allow the next track to immediately start playing. If they prefetch too early the bandwidth may be wasted if the user then makes a random request The clients begin searching the peer-to-peer network and start downloading the next track when 30 seconds or less remain of the current track. When 10 seconds or less remain of the current track, the client prefetches the beginning of the next track from the server if needed
• #19: Streaming applications need to employ some mechanism to combat the effects of packet packet loss and packet delay variation. trade-off between initial playback latency, receiver buffer size, and the stutter free probability The client performs 100 simulations and if more than one of them fails, it waits longer before beginning playback. During these simulations the client makes the simplifying assumption that data is consumed at a constant rate despite the fact that the codec used has a variable bitrate encoding
• #23: Peers remember the 50 most recent searches Priority of interests: currently streaming track, prefetching next track, and offline synchronization
• #26: Peers remember the 50 most recent searches Priority of interests: currently streaming track, prefetching next track, and offline synchronization
• #27: the peers with the least total scores are disconnected The client simultaneously uploads to at most 4 peers.
• #28: one would expect that this would constitute a problem as users are likely to be situated behind various NAT devices
• #32: Mostly minor variations over time 1) Better P2P performance on weekends 2) P2P most effective at peak hours large caches and peer-to-peer network together significantly decrease the load on Spotify’s servers
• #33: We are not aware of any studies discussing in detail how user’s satisfaction with a streaming service depends on these two factors, but we believe them to be very important
• #34: We observe that the latency is significantly lower during the night, when the number of tracks played is also low. This is mainly due to two reasons. Firstly, more data is played from the cache during the night. Secondly, users are less interactive during the night, allowing the prefetching