MultimediaCC - Cronologia

Ldecicco il 15:44, 23 Mag 2019

2019-05-23T15:44:13Z

Ldecicco: Riportata alla revisione precedente da SMascolo

2019-05-23T15:41:09Z

Riportata alla revisione precedente da SMascolo

Ldecicco il 15:40, 23 Mag 2019

2019-05-23T15:40:05Z

SMascolo il 19:23, 11 Gen 2017

2017-01-11T19:23:43Z

SMascolo il 10:21, 31 Mag 2016

2016-05-31T10:21:09Z

SMascolo il 10:19, 31 Mag 2016

2016-05-31T10:19:15Z

Ldecicco il 11:10, 22 Mag 2016

2016-05-22T11:10:12Z

Ldecicco il 17:10, 9 Feb 2016

2016-02-09T17:10:39Z

Ldecicco il 17:07, 9 Feb 2016

2016-02-09T17:07:05Z

Ldecicco il 17:06, 9 Feb 2016

2016-02-09T17:06:55Z

@@ Riga 18: / Riga 18: @@
 </ul>
 }}
-A description of the algorithm is provided in the IETF RMACT draft.
+A description of the algorithm is provided in the IETF RMACT draft and in a paper published in the IEEE/ACM Transactions on Networking:
 <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>
@@ Riga 27: / Riga 32: @@
 [[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.
+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">
@@ Riga 51: / Riga 56: @@
 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="Proc. ACM Mmsys 2016" place="Klagenfurt, Austria" date="May 2016" pdf="gcc-analysis.pdf">
@@ Riga 61: / Riga 71: @@
 <br>
-Fig. below  shows how rate flows dynamics along with one way delay variations are nicely set after the introduction of the adaptive threshold.
+Fig. below shows how rate flows dynamics along with one-way delay variations are nicely set after the introduction of the adaptive threshold.
 <br>
@@ Riga 67: / Riga 77: @@
 == 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 resource for co-existing best-effort TCP traffic.
+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">

@@ Riga 26: / Riga 26: @@
 == 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">

@@ Riga 26: / Riga 26: @@
 == 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">

@@ Riga 6: / Riga 6: @@
 {{Panel|type=primary|icon=wrench|title=Google Faculty Research Award|body=
-<absHTML><img src="http://research.google.com/images/faculty_award.png" alt="Smiley face" width="240" > </img>
+<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.

@@ Riga 50: / Riga 50: @@
 <br>
-To overcome these issues, we have proposed the adaptive threshold mechanism which sets the threshold g(i) used by the over-use detector.
+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="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>

←Older revision		Revisione 11:10, 22 Mag 2016
Riga 51:		Riga 51:

	To overcome these issues, we have proposed the adaptive threshold mechanism in the last version of the IETF draft which sets the threshold g(i) used by the over-use detector.		To overcome these issues, we have proposed the adaptive threshold mechanism in the last version of the IETF draft which sets the threshold g(i) used by the over-use detector.
		+
		+	<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="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">		<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">

@@ Riga 3: / Riga 3: @@
 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) which is today used in Google Chrome and Google Hangouts.
+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.
 {{Panel|type=primary|icon=wrench|title=Google Faculty Research Award|body=
@@ Riga 18: / Riga 18: @@
 </ul>
 }}
 <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