(Skype Video Congestion Control)
 
(42 versioni intermedie di 3 utenti non mostrate)
Riga 1: Riga 1:
 
[[Category:Research]]
 
[[Category:Research]]
=Congestion Control for Multimedia Applications=
+
=Congestion Control for Real-time Communication=
The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have evaluated the congestion control strategies employed by leading multimedia applications such as  Skype for VoIP applications and RealNetworks  video on demand applications. We have found that both applications don't employ an efficient congestion control scheme.
+
Congestion control for Real-Time media communication (Video-conferencing, Voice over IP) over the Internet is currently being addressed in IETF
[[Immagine:Multimedia-cc.png|right|thumb|400px|''Multimedia application'']]
+
and W3C bodies aiming at standardizing a set of inter-operable protocols and APIs to enable real-time communication between Web browsers.
 +
The IETF working group (WG) RTP Media Congestion Avoidance Techniques (RMCAT) has been established in 2012 to propose the standardization of congestion control algorithms using the RTP. We are developing a congestion control algorithm for Web Real-time Communication (WebRTC). The proposed algorithm is used in Google Chrome and Google Hangouts.  
  
== Skype Video Responsiveness to Bandwidth Variations ==
+
{{Panel|type=primary|icon=wrench|title=Google Faculty Research Award|body=
 +
<absHTML><img src="http://c3lab.poliba.it/images/e/e8/Google-award.png" alt="Smiley face" width="240" > </img>
 +
</absHTML>
 +
<b>[[GoogleFacultyAward | Google Faculty Award 2014]]</b> for designing a congestion control algorithm for real-time communication within the WebRTC framework to enable video conference among Web browsers.
 +
<ul>
 +
<li>Principal investigator: <b> S. Mascolo </b></li>
 +
<li>Title:<b>Congestion Control for Web Real-Time Communication (WebRTC)</b>
 +
<li>August 2014</li>
 +
</li>
 +
<li>Press coverage: [http://bari.repubblica.it/cronaca/2014/09/02/news/google-94895337/ Link]
 +
</li>
 +
</ul>
 +
}}
 +
A description of the algorithm is provided in the IETF RMACT draft and in a paper published in the IEEE/ACM Transactions on Networking:
  
Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples  are  YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Skype VoIP or Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resource for co-existing best-effort TCP traffic.
+
<paper authors="S. Holmer, H. Lundin, G. Carlucci, L. De Cicco, and S. Mascolo" conference="IETF draft RMCAT wg" place="draft-ietf-rmcat-gcc-01" date="Oct 2015" url="https://tools.ietf.org/html/draft-ietf-rmcat-gcc-01">
 +
A Google Congestion Control Algorithm for Real-Time Communication                 
 +
</paper>
 +
 
 +
<paper authors="G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo" conference="IEEE/ACM Transactions on Networking" date="vol. 25, no. 5, pp. 2629-2642, Oct. 2017.
 +
doi: 10.1109/TNET.2017.2703615" pdf="gcc-TNET.pdf">
 +
Congestion Control for Web Real-Time Communication
 +
</paper>
 +
 
 +
== Google Congestion Control for WebRTC ==
 +
[[Immagine:WebRTCArc.jpg|center|''System Architecture'']]
 +
Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples  are  YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer.  
 +
In these papers we experimentally evaluate the Google Congestion Control (GCC) which has been proposed in the RMCAT IETF WG. By setting up a controlled testbed, we have evaluated to what extent GCC flows are able to track the available bandwidth while minimizing queuing delays, and fairly share the bottleneck with other GCC or TCP flows. We have found that the algorithm works as expected when a GCC flow accesses the bottleneck in isolation, whereas it is not able to provide a fair bandwidth utilization when a GCC flow shares the bottleneck with either a GCC or a TCP flow.
 +
 
 +
<paper authors="L. De Cicco, G. Carlucci, and S. Mascolo" conference="Packet Video Workshop" date="2013" place="San Jose, CA, USA" pdf="Gcc-pv-2013.pdf" slides="gcc-slides-pv2013.pdf">
 +
Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb
 +
</paper>
 +
 
 +
<paper authors="L. De Cicco, G. Carlucci, and S. Mascolo" conference="ACM SIGCOMM 2013 Workshop on Future Human-Centric Multimedia Networking" place="Hong Kong, China" date="August 2013" pdf="webrtc_cc-Fhcmn2013.pdf">
 +
Experimental Investigation of the Google Congestion Control for Real-Time Flows</paper>
 +
 
 +
<br>
 +
 
 +
[[Immagine:GCCArc.png|center|1000px|''Google Congestion Control Architecture'']]
 +
 
 +
<br>
 +
 
 +
Our experimental investigation has shown that the first version of GCC gets starved when a TCP flow joins the bottleneck (see Fig. below (a)). Moreover, we have found that starvation also occurs when two coexisting GCC flows share a bottleneck (see Fig. below (b) (c)).
 +
 
 +
<br>
 +
 
 +
[[Immagine:GCCIssue.png|center|850px|''Google Congestion Control Fairness Issues'']]
 +
 
 +
<br>
 +
 
 +
To overcome these issues, we have proposed the adaptive threshold mechanism which sets the threshold used by the over-use detector. More details can be found in the following papers:
 +
 
 +
<paper authors="G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo" conference="IEEE/ACM Transactions on Networking" date="vol. 25, no. 5, pp. 2629-2642, Oct. 2017.
 +
doi: 10.1109/TNET.2017.2703615" pdf="gcc-TNET.pdf">
 +
Congestion Control for Web Real-Time Communication
 +
</paper>
 +
 
 +
<paper authors="G. Carlucci, L. De Cicco,  S. Holmer, and S. Mascolo" conference="Proc. ACM Mmsys 2016" place="Klagenfurt, Austria" date="May 2016" pdf="gcc-analysis.pdf">
 +
Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)
 +
</paper>
 +
 
 +
<paper authors=" Gaetano Carlucci, Luca De Cicco,Saverio Mascolo" conference="Proc. of 53rd IEEE Conference on Decision and Control" place="Los Angeles, California, USA" date="December 2014" pdf="gcc-cdc-2014.pdf">
 +
Modelling and Control for Web Real-Time Communication
 +
</paper>
 +
 
 +
<br>
 +
Fig. below shows how rate flows dynamics along with one-way delay variations are nicely set after the introduction of the adaptive threshold.
 +
<br>
 +
 
 +
[[Immagine:ATGCC.jpg|center|850px|''Google Congestion Control with adaptive threshold']]
 +
 
 +
== Skype Video Congestion Control Responsiveness to Bandwidth Variations  ==
 +
This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resources for co-existing best-effort TCP traffic.
  
 
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="skype-video_nossdav08.pdf" conference="ACM NOSSDAV '08" place="Braunschweig, Germany">
 
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="skype-video_nossdav08.pdf" conference="ACM NOSSDAV '08" place="Braunschweig, Germany">
Riga 43: Riga 114:
 
[[Immagine:skype_vs_skype.png|right|thumb|550px|''Two Skype flows sharing the same bottleneck'']]
 
[[Immagine:skype_vs_skype.png|right|thumb|550px|''Two Skype flows sharing the same bottleneck'']]
  
 +
<!--
 
== Apple Darwin Streaming Server Congestion Control ==
 
== Apple Darwin Streaming Server Congestion Control ==
  
Riga 56: Riga 128:
 
We have evaluated how Helix Player behaves when available bandwidth reductions take place in order to find out how it reacts to congestion episodes. The figure below shows how the throughput of an helix connection experiences up to 30% of packet losses when another helix flow enters the link at 30s and exits at 90s.  
 
We have evaluated how Helix Player behaves when available bandwidth reductions take place in order to find out how it reacts to congestion episodes. The figure below shows how the throughput of an helix connection experiences up to 30% of packet losses when another helix flow enters the link at 30s and exits at 90s.  
 
[[Immagine:helix-cc.png|right|thumb|400px|''Two Helix flows sharing a bottleneck'']]
 
[[Immagine:helix-cc.png|right|thumb|400px|''Two Helix flows sharing a bottleneck'']]
 +
-->
 +
==Relevant bibliography==
 +
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" conference="Computer Newtorks, Elsevier" place="in press, doi 10.1016/j.comnet.2010.09.010" date="2010">
 +
Skype Video Congestion Control: an Experimental Investigation
 +
</paper>
 +
 +
<paper authors="L. De Cicco, S. Mascolo" date="2010"  conference="IEEE Transactions on Automatic Control, to appear">
 +
A Mathematical Model of the Skype VoIP Congestion Control Algorithm
 +
</paper>
 +
 +
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="Dec, 2008" pdf="skype_voip_model.pdf" conference="in Proc. of IEEE Conference on Decision and Control 2008" place="Cancun, Mexico">
 +
A Mathematical Model of the Skype VoIP Congestion Control Algorithm
 +
</paper>
  
{{MantainedLDC}}
+
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="skype-video_nossdav08.pdf" slides="skype-video_nossdav08_slides.pdf"  conference="NOSSDAV '08" place="Braunschweig, Germany">
 +
Skype Video Responsiveness to Bandwidth Variations
 +
</paper>
 +
 
 +
<paper authors="L. De Cicco, S. Mascolo, V. Palmisano" date="May, 2008" pdf="darwin-cc.pdf" conference="Wired/Wireless Internet Communications (WWIC) 2008">
 +
An Experimental Investigation of the End-to-End QoS of the Apple Darwin Streaming Server
 +
</paper>
 +
 
 +
<paper authors="L. De Cicco, S. Mascolo and V. Palmisano" date="May, 2007" pdf="skype_wwic07.pdf" slides="skype_wwic07_slides.pdf" conference="Wired/Wireless Internet Communications (WWIC) 2007" place="Coimbra, Portugal" >
 +
An Experimental Investigation of the Congestion Control Used by Skype VoIP
 +
</paper>
 +
 
 +
<paper authors="L.A. Grieco, S. Mascolo," conference="ACM Multimedia Systems Journal, Regular paper" date="Jun. 2004" place="Volume 9, Issue 6, pp. 517 - 532" >
 +
Adaptive Rate Control for Streaming Flows over the Internet
 +
</paper>

Versione attuale delle 15:44, 23 Mag 2019

Congestion Control for Real-time Communication

Congestion control for Real-Time media communication (Video-conferencing, Voice over IP) over the Internet is currently being addressed in IETF and W3C bodies aiming at standardizing a set of inter-operable protocols and APIs to enable real-time communication between Web browsers. The IETF working group (WG) RTP Media Congestion Avoidance Techniques (RMCAT) has been established in 2012 to propose the standardization of congestion control algorithms using the RTP. We are developing a congestion control algorithm for Web Real-time Communication (WebRTC). The proposed algorithm is used in Google Chrome and Google Hangouts.

Google Faculty Research Award

Smiley face

Google Faculty Award 2014 for designing a congestion control algorithm for real-time communication within the WebRTC framework to enable video conference among Web browsers.

  • Principal investigator: S. Mascolo
  • Title:Congestion Control for Web Real-Time Communication (WebRTC)
  • August 2014
  • Press coverage: Link

A description of the algorithm is provided in the IETF RMACT draft and in a paper published in the IEEE/ACM Transactions on Networking:

  • S. Holmer, H. Lundin, G. Carlucci, L. De Cicco, and S. Mascolo
    A Google Congestion Control Algorithm for Real-Time Communication
    IETF draft RMCAT wg, draft-ietf-rmcat-gcc-01, Oct 2015 (Web: Link)
  • G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
    Congestion Control for Web Real-Time Communication
    IEEE/ACM Transactions on Networking, vol. 25, no. 5, pp. 2629-2642, Oct. 2017. doi: 10.1109/TNET.2017.2703615 (PDF)

Google Congestion Control for WebRTC

System Architecture

Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples are YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. In these papers we experimentally evaluate the Google Congestion Control (GCC) which has been proposed in the RMCAT IETF WG. By setting up a controlled testbed, we have evaluated to what extent GCC flows are able to track the available bandwidth while minimizing queuing delays, and fairly share the bottleneck with other GCC or TCP flows. We have found that the algorithm works as expected when a GCC flow accesses the bottleneck in isolation, whereas it is not able to provide a fair bandwidth utilization when a GCC flow shares the bottleneck with either a GCC or a TCP flow.

  • L. De Cicco, G. Carlucci, and S. Mascolo
    Understanding the Dynamic Behaviour of the Google Congestion Control for RTCWeb
    Packet Video Workshop, San Jose, CA, USA, 2013 (PDF) (Slides:PDF)
  • L. De Cicco, G. Carlucci, and S. Mascolo
    Experimental Investigation of the Google Congestion Control for Real-Time Flows
    ACM SIGCOMM 2013 Workshop on Future Human-Centric Multimedia Networking, Hong Kong, China, August 2013 (PDF)


Google Congestion Control Architecture


Our experimental investigation has shown that the first version of GCC gets starved when a TCP flow joins the bottleneck (see Fig. below (a)). Moreover, we have found that starvation also occurs when two coexisting GCC flows share a bottleneck (see Fig. below (b) (c)).


Google Congestion Control Fairness Issues


To overcome these issues, we have proposed the adaptive threshold mechanism which sets the threshold used by the over-use detector. More details can be found in the following papers:

  • G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
    Congestion Control for Web Real-Time Communication
    IEEE/ACM Transactions on Networking, vol. 25, no. 5, pp. 2629-2642, Oct. 2017. doi: 10.1109/TNET.2017.2703615 (PDF)
  • G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
    Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)
    Proc. ACM Mmsys 2016, Klagenfurt, Austria, May 2016 (PDF)
  • Gaetano Carlucci, Luca De Cicco,Saverio Mascolo
    Modelling and Control for Web Real-Time Communication
    Proc. of 53rd IEEE Conference on Decision and Control, Los Angeles, California, USA, December 2014 (PDF)


Fig. below shows how rate flows dynamics along with one-way delay variations are nicely set after the introduction of the adaptive threshold.

Google Congestion Control with adaptive threshold'

Skype Video Congestion Control Responsiveness to Bandwidth Variations

This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resources for co-existing best-effort TCP traffic.

  • L. De Cicco, S. Mascolo, V. Palmisano
    Skype Video Responsiveness to Bandwidth Variations
    ACM NOSSDAV '08, Braunschweig, Germany, May, 2008 (PDF)

Skype VoIP Congestion Control

Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.

Next figures summarize main findings (more can be found in the paper: "An Experimental Investigation of the Congestion Control Used by Skype VoIP" pdf and slides).

Skype implements some mechanism to adapt the input rate to the available bandwidth

One Skype flow over a square waveform available bandwidth

The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates.

Skype adapts to the available bandwidth very slowly

For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure.

One Skype flow over a square waveform available bandwidth (higher frequency than before)


Skype is not TCP friendly

Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows.

One Skype flow versus one TCP flow

The Figure above shows that TCP connection suffers a large number of timeouts.

Skype is not able to guarantee fairness either

Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness.

Two Skype flows sharing the same bottleneck

Relevant bibliography

  • L. De Cicco, S. Mascolo, V. Palmisano
    Skype Video Congestion Control: an Experimental Investigation
    Computer Newtorks, Elsevier, in press, doi 10.1016/j.comnet.2010.09.010, 2010
  • L. De Cicco, S. Mascolo
    A Mathematical Model of the Skype VoIP Congestion Control Algorithm
    IEEE Transactions on Automatic Control, to appear, 2010
  • L. De Cicco, S. Mascolo, V. Palmisano
    A Mathematical Model of the Skype VoIP Congestion Control Algorithm
    in Proc. of IEEE Conference on Decision and Control 2008, Cancun, Mexico, Dec, 2008 (PDF)
  • L. De Cicco, S. Mascolo, V. Palmisano
    Skype Video Responsiveness to Bandwidth Variations
    NOSSDAV '08, Braunschweig, Germany, May, 2008 (PDF) (Slides:PDF)
  • L. De Cicco, S. Mascolo, V. Palmisano
    An Experimental Investigation of the End-to-End QoS of the Apple Darwin Streaming Server
    Wired/Wireless Internet Communications (WWIC) 2008, May, 2008 (PDF)
  • L. De Cicco, S. Mascolo and V. Palmisano
    An Experimental Investigation of the Congestion Control Used by Skype VoIP
    Wired/Wireless Internet Communications (WWIC) 2007, Coimbra, Portugal, May, 2007 (PDF) (Slides:PDF)
  • L.A. Grieco, S. Mascolo,
    Adaptive Rate Control for Streaming Flows over the Internet
    ACM Multimedia Systems Journal, Regular paper, Volume 9, Issue 6, pp. 517 - 532, Jun. 2004

Congestion Control for Multimedia Applications[edit]

The congestion control for multimedia applications (Voice over IP, video on demand) is an open issue. We have evaluated the congestion control strategies employed by leading multimedia applications such as Skype for VoIP applications and RealNetworks video on demand applications. We have found that both applications don't employ an efficient congestion control scheme.

Multimedia application

Skype Video Responsiveness to Bandwidth Variations[edit]

Nowadays, the Internet is rapidly evolving to become an equally efficient platform for multimedia content delivery. Key examples are YouTube, Skype Audio/Video, IPTV, P2P video distribution platforms such as Coolstreaming or Joost, to name few. While YouTube streams videos using the Transmission Control Protocol (TCP), applications that are time-sensitive such as Skype VoIP or Video Conferencing employ the UDP because they can tolerate small loss percentages but not delays due to TCP recovery of losses via retransmissions. Since the UDP does not implement congestion control, these applications must implement those functionalities at the application layer. This paper investigates Skype Video in order to discover at what extent this application is able to throttle its sending rate to match the unpredictable Internet bandwidth while preserving resource for co-existing best-effort TCP traffic.

Skype VoIP Congestion Control[edit]

Skype is the most popular VoIP application with over 250 million userbase spread all over the world. It is important to study how skype reacts to packet losses in order to infer if a huge amount of skype calls can result in a congestion collapse.

Next figures summarize main findings (more can be found in the paper: "An Experimental Investigation of the Congestion Control Used by Skype VoIP" pdf and slides).

Skype implements some mechanism to adapt the input rate to the available bandwidth[edit]

One Skype flow over a square waveform available bandwidth

The figure shows the sending rate, the loss rate and the available bandwidth. It can be noticed that Skype adapts its sending rate when the available bandwidth decreases but this adaptation takes 40s, thus leading to high packet loss rates.

Skype adapts to the available bandwidth very slowly[edit]

For the before mentioned reason Skype is not able to cope with sudden bandwidth variations as it can be seen in the next figure.

One Skype flow over a square waveform available bandwidth (higher frequency than before)


Skype is not TCP friendly[edit]

Skype's response to bandwidth variation is sluggish and leads to unfriendliness with respect to TCP flows.

One Skype flow versus one TCP flow

The Figure above shows that TCP connection suffers a large number of timeouts.

Skype is not able to guarantee fairness either[edit]

Two Skype calls have been placed flowing in the same bottleneck in order to investigate if Skype's congestion control is able to guarantee fairness.

Two Skype flows sharing the same bottleneck

Apple Darwin Streaming Server Congestion Control[edit]

We investigated the end-to-end quality of service (QoS) that is provided by the Apple Darwin Streaming Server and the Quick-Time client player in the presence of time-varying available bandwidth and multiple concurrent streaming sessions.

More can be found in the paper: An Experimental Investigation of the End-to-End QoS of the Apple Darwin Streaming Server (pdf).

Helix Player Congestion Control (RealPlayer by RealNetworks)[edit]

We have evaluated how Helix Player behaves when available bandwidth reductions take place in order to find out how it reacts to congestion episodes. The figure below shows how the throughput of an helix connection experiences up to 30% of packet losses when another helix flow enters the link at 30s and exits at 90s.

Two Helix flows sharing a bottleneck

This page is mantained by Luca De Cicco, please send feedback to ldecicco at gmail DOT com