{"id":171470,"date":"2015-05-28T03:23:24","date_gmt":"2015-05-28T03:23:24","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/project\/pindrop\/"},"modified":"2017-09-13T02:37:12","modified_gmt":"2017-09-13T09:37:12","slug":"pindrop","status":"publish","type":"msr-project","link":"https:\/\/www.microsoft.com\/en-us\/research\/project\/pindrop\/","title":{"rendered":"PinDrop"},"content":{"rendered":"
The PinDrop project focuses on building the substrate for supporting high-quality real-time streaming over wired and wireless networks.<\/p>\n
Real-time streaming across the wide-area network (WAN) is key to several existing and anticipated services, including voice and video conferencing (e.g., Skype, Viber), remote console access (e.g., remote desktop,\u00a0VNC),\u00a0remote application streaming (e.g., Azure RemoteApp), and cloud-based gaming. A common characteristic of these services is bidirectional interactive<\/em> communication, between two or more users or between a user and a remote service such as a cloud-hosted application or game. Therefore, these applications place stringent demands on the network not only in terms of bandwidth but also\u00a0latency, jitter, packet loss, and availability. For example, VoIP would require an end-to-end round-trip time (RTT) of no more than 300 ms, otherwise users will notice a lag. With cloud-based gaming, the latency requirement is even more stringent, with an RTT of no more than 60 ms needed in some cases.<\/p>\n As against these demands of real-time streaming applications, the Internet largely remains a best-effort network that provides undifferentiated service, with no guarantees on latency, packet loss, or even bandwidth. While there have been many research proposals and even some standardization activity aimed at providing real-time guarantees or preferential treatment for real-time flows, these have received limited traction and seen inconsistent deployment. There are also various technical and policy impediments, even where these mechanisms have been deployed. For example, the differentiated services code point (DSCP) contained in the IP header for DiffServ is typically not preserved across ISP boundaries, limiting its usefulness as a mechanism for prioritization. Furthermore, similar prioritization mechanism called wireless multimedia extensions, which is part of the 802.11e standard for WiFi,\u00a0is of little utility, say when the link is lossy due to wireless interference.<\/p>\n The result is that even as real-time streaming applications have moved into the mainstream over the past decade, it is not uncommon for these to suffer a noticeable degradation in performance. Indeed, the reliability of VoIP is a far cry from the five 9s service provided by traditional telephony. Thus, there is a clear need to bridge the gap between the needs of real-time streaming and the best-effort service provided by the network.<\/p>\n For the first time, we have applications such as Skype that\u00a0exercise\u00a0a wide swathe of the Internet\u00a0through peer-to-peer\u00a0paths, in a manner\u00a0that few cloud-to-client services do.\u00a0The geo-distributed footprint of users of these applications presents us with\u00a0an exciting opportunity to derive Internet-wide insights and use these to improve performance.<\/p>\n\t\t\t