C3Lab - Contributi di questo Utente [it]

Template:Projects

2026-05-12T14:29:26Z

CarloCroce:

* "ARtIficiAl iNtelligeNce for virtuAl meetings (ARIANNA)" - '''PR PUGLIA FESR''' (2021-2027)
* "LOw-delay congestion control for REal-time applications over the iNternet (LOREN)" - "Funded by NextGenerationEU"
* "a Cloud-based pLatform for Immersive adaPtive video Streaming ([[CLIPS|CLIPS]])" - '''Funded by MISE''' (2017-2020)
* "Congestion control algorithm for Web real-time communication (WebRTC)." - '''[http://c3lab.poliba.it/index.php?title=GoogleFacultyAward Google Faculty Award 2014 ]'''
* "Progetto PAC '''[https://sites.google.com/site/maivistostartup/ MAIVISTO]''' (Massive Adaptive Video STreaming over the Internet Using the Cloud)" - '''Funded by MIUR''' (2014-2016)
* "Architecture for Robust and Efficient Control of Dynamic Adaptive Video Streaming over HTTP." - '''[http://c3lab.poliba.it/index.php?title=Awards Cisco Academy Research Award (CG #574954)]''' March 2013.
* "PLATform for INnOvative services in future internet" '''[https://sites.google.com/site/progettoplatino/ PON PLATINO]''', 2012-2015, funded by MIUR
* "RES Novae" (Reti, Edifici, Strade - nuovi obiettivi virtuosi per l'ambiente e l'energia), 2012-2015, funded by MIUR
* "End-to-end protocols for video over IP", 2008-2009, funded by Financial Tradeware plc
* '''[http://www.tnt.dist.unige.it/famous/index.php FAMOUS]''' (PRIN)
* "End-to-End protocols for audio/video over Internet protocol", 2005-2006, funded by Financial Tradeware plc
* '''[[Westwood | TCP Westwood+]]''' This protocol was an outcome of the [http://tango.isti.cnr.it/ TANGO] project
* Cost 290
* '''[http://www.signal.uu.se/Research/PCCwirelessIP.html WIP]''' (Wireless Internet Protocol)

Template:Projects

2026-05-12T14:28:49Z

CarloCroce:

* "ARtIficiAl iNtelligeNce for virtuAl meetings (ARIANNA)" - "PR PUGLIA FESR" (2021-2027)
* "LOw-delay congestion control for REal-time applications over the iNternet (LOREN)" - "Funded by NextGenerationEU"
* "a Cloud-based pLatform for Immersive adaPtive video Streaming ([[CLIPS|CLIPS]])" - '''Funded by MISE''' (2017-2020)
* "Congestion control algorithm for Web real-time communication (WebRTC)." - '''[http://c3lab.poliba.it/index.php?title=GoogleFacultyAward Google Faculty Award 2014 ]'''
* "Progetto PAC '''[https://sites.google.com/site/maivistostartup/ MAIVISTO]''' (Massive Adaptive Video STreaming over the Internet Using the Cloud)" - '''Funded by MIUR''' (2014-2016)
* "Architecture for Robust and Efficient Control of Dynamic Adaptive Video Streaming over HTTP." - '''[http://c3lab.poliba.it/index.php?title=Awards Cisco Academy Research Award (CG #574954)]''' March 2013.
* "PLATform for INnOvative services in future internet" '''[https://sites.google.com/site/progettoplatino/ PON PLATINO]''', 2012-2015, funded by MIUR
* "RES Novae" (Reti, Edifici, Strade - nuovi obiettivi virtuosi per l'ambiente e l'energia), 2012-2015, funded by MIUR
* "End-to-end protocols for video over IP", 2008-2009, funded by Financial Tradeware plc
* '''[http://www.tnt.dist.unige.it/famous/index.php FAMOUS]''' (PRIN)
* "End-to-End protocols for audio/video over Internet protocol", 2005-2006, funded by Financial Tradeware plc
* '''[[Westwood | TCP Westwood+]]''' This protocol was an outcome of the [http://tango.isti.cnr.it/ TANGO] project
* Cost 290
* '''[http://www.signal.uu.se/Research/PCCwirelessIP.html WIP]''' (Wireless Internet Protocol)

MetodiDiControllo

2025-12-03T10:13:23Z

CarloCroce:

{{Mascolo}}
__NOTOC__

== Control of network systems (6 crediti) - A.A 2022-2023==
The course introduces the state space approach, the state feedback, the observer design, the state decomposition, the Kalman filtering with application to important case studies such as: GooglePageRank, network congestion contro, TCP congestion control, adaptive videostreaming, cryptography using observers, deep learning for controlling QoE in video streaming.
System implementation using kubernets.

==Modalità di esame ==
L'esame comprende una prova scritta, una prova orale in cui si discutono 3 articoli scientifici a scelta tra quelli studiati durante il corso e un tema d'anno. Il voto finale è la media della prova scriita, della prova orale e del tema d'anno.

===Control methods for computer networks - Laurea Magistrale in Ingegneria Informatica e ing. Telecomunicazioni A.A. 2022/23===

===Programma===
Descrizione nello spazio degli Stati. Realizzazione. Osservabilità e Controllabilità. Retroazione di stato. Osservatore di stato. Retroazione e osservatore: sintesi del regolatore ed esempi. Sincronizzazione di sistemi caotici e applicazioni alla crittografia con tecniche basate sugli osservatori. Il filtro di Kalman. Il controllo di congestione nella rete Internet. Smith predictor e controllo di congestione.Controllo rate-base e window based. Il TCP friendly rate control (2 ore). TCP Reno/NewReno, Vegas, Westwood+. Il video streaming adattivo. Il controllo di congestion per WebRTC di Google. Controllo attivo delle code (AQM). Il controllo di congestione nel kernel di Linux. WebRTC. PageRank. Esperimenti di laboratorio con con software di simulazione. Caso di studio: la WebTV del Politecnico di Bari.
===Laurea Magistrale in Ingegneria Informatica A.A. 2015/16===

===Programma===
Descrizione nello spazio degli Stati. Realizzazione. Osservabilità e Controllabilità. Retroazione di stato. Osservatore di stato. Retroazione e osservatore: sintesi del regolatore ed esempi. Sincronizzazione di sistemi caotici e applicazioni alla crittografia con tecniche basate sugli osservatori. Il filtro di Kalman. Tecniche di controllo non lineare. Definizione di stabilita' dello stato di equilibrio alla Lyapunov. Forme quadratiche. Equazione di Lyapunov. Criteri di stabilita' diretto e indiretto (mediante linearizzazione) dello stato di equilibrio. Il controllo di congestione nella rete Internet. Smith predictor e controllo di congestione.Controllo rate-base e window based. Il TCP friendly rate control (2 ore). TCP Reno/NewReno, Vegas, Westwood+. Il video streaming adattivo. Il controllo di congestion per WebRTC di Google. Controllo attivo delle code (AQM). Il controllo di congestione nel kernel di Linux. WebRTC. PageRank. Esperimenti di laboratorio con con software di simulazione. Caso di studio: la WebTV del Politecnico di Bari.

===Control methods for computer networks - Laurea Magistrale in Ingegneria Informatica A.A. 2014/15===

===Programma===
Descrizione nello spazio degli Stati. Realizzazione. Osservabilità e Controllabilità. Retroazione di stato. Osservatore di stato. Retroazione e osservatore: sintesi del regolatore ed esempi. Sincronizzazione di sistemi caotici e applicazioni alla crittografia con tecniche basate sugli osservatori. Il filtro di Kalman. Tecniche di controllo non lineare. Definizione di stabilita' dello stato di equilibrio alla Lyapunov. Forme quadratiche. Equazione di Lyapunov. Criteri di stabilita' diretto e indiretto (mediante linearizzazione) dello stato di equilibrio. Il controllo di congestione nella rete Internet. Smith predictor e controllo di congestione.Controllo rate-base e window based. Il TCP friendly rate control (2 ore). TCP Reno/NewReno, Vegas, Westwood+. Il video streaming adattivo. Il controllo di congestion per WebRTC di Google. Controllo attivo delle code (AQM). Il controllo di congestione nel kernel di Linux. WebRTC. Esperimenti di laboratorio con con software di simulazione. Caso di studio: la WebTV del Politecnico di Bari.

===Laurea Magistrale in Ingegneria Informatica A.A. 2013/14===
=== Control methods for computer networks===

Il corso ha l’obiettivo di integrare le conoscenze fornite nei corsi di Fondamenti di Automatica I e Fondamenti di Automatica II con tecniche di controllo di particolare interesse nel campo delle reti di computer.

===Programma===
Descrizione nello spazio degli Stati. Realizzazione. Osservabilità e Controllabilità. Retroazione di stato. Osservatore di stato. Retroazione e osservatore: sintesi del regolatore ed esempi. Sincronizzazione di sistemi caotici e applicazioni alla crittografia con tecniche basate sugli osservatori. Tecniche di controllo non lineare. Definizione di stabilita' dello stato di equilibrio alla Lyapunov. Forme quadratiche. Equazione di Lyapunov. Criteri di stabilita' diretto e indiretto (mediante linearizzazione) dello stato di equilibrio. Il controllo di congestione nella rete Internet. Smith predictor e controllo di congestione.Controllo rate-base e window based. Il TCP friendly rate control (2 ore). TCP Reno/NewReno, Vegas, Westwood+. Il controllo di congestione nelle reti a 10Gbps. Il video streaming adattivo. Il controllo in retroazione per la qualità del servizio su reti IEEE 802.11. Controllo attivo delle code. I sistemi peer-to-peer . Il controllo di congestione in Skype. PageRank. Il controllo di congestione nel kernel di Linux. WebRTC. Esperimenti di laboratorio con con software di simulazione. Caso di studio: la WebTV del Politecnico di Bari.

===Testi di rferimento ===
*Appunti dalle lezioni
*Articoli
*J. Hellerstein, Y Diao, S. Parekh, D.M. Tilbury, Feedback control of computing systems, John Wiley 2004
*Gene F. Franklin, J. David Powell, Abbas Emami-Naeini, Feedback Control of Dynamic Systems, Addison-Wesley, 2002
*Slotine, Nonlinear applied control, Prenhall

=== Materiale di approfondimento sui casi di studio ===
* [https://arxiv.org/pdf/2507.00896 QUIC Delay Control: an implementation of congestion and delay control]
* [https://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf Experimental Investigation of the Google Congestion Control for Real-Time Flows]
* [https://arxiv.org/ftp/arxiv/papers/1805/1805.01631.pdf On continuos versus discrete time models]
* [[Media:AQM-HOLLOT.pdf | Linearizzazione AQM]],
* [[Media:automatica.pdf | smith predictor TCP]],
* [[Media:controlengpractice.pdf | modelling TCP]],
* [[Media:CasOct97.pdf | sincronizzazione con osservatore]],
* [[Media:CasSep99.pdf | sincronizzazione + osservatore + crittografia]],
* [[Media:Mobi2001.pdf | TCP Westwood]],
* [[Media:ccr_v31.pdf | TCP Westwood+]],
* [[Media:MMSYS2011.pdf | Adaptive streaming]],
* [[Media:vanjacobson.pdf |TCP Van Jacobson]],
* [[Media:automatica.pdf | Congestion control in high-speed communication networks using the Smith principle]],
* [http://c3lab.poliba.it/images/a/a1/Elastic-pv2013.pdf ELASTIC: a Client-side Controller for Dynamic Adaptive Streaming over HTTP (DASH)] (si veda anche [http://c3lab.poliba.it/images/b/b1/Acc2015.pdf "Characterizing Adaptive Video Streaming Control Systems"] per il modello del playout buffer)
* [https://c3lab.poliba.it/images/c/c4/Gcc-TNET.pdf Google Congestion Control for Web Real-time communication (WebRTC)]
* [http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf Skype Video Congestion Control: an Experimental Investigation]
* [http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf A Mathematical Model of the Skype VoIP Congestion Control Algorithm]
* [http://c3lab.poliba.it/images/3/3f/Avs_tnet_decicco_mascolo.pdf An Adaptive Video Streaming Control System: Modeling, Validation, and Performance Evaluation]
* [[Media:contrecc.pdf | Using control theory for reccomender system]],
* [http://c3lab.poliba.it/images/0/0c/Page_rank.pdf Page Rank],
* [[Media:Web_Information_Retrieval.pdf | A Survey of Eigenvector Methods of Web Information Retrieval]]
* [[Media:tcp_mathis.pdf | The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm]]
* [https://static.googleusercontent.com/media/research.google.com/it//pubs/archive/35179.pdf The unreasonable effectiveness of data]
* [https://maths-it.org.uk/Wigner.html The unreasonable effectiveness of Mathematics in the Natural Sciences]
*[https://www.teunisott.com/Papers/TCP_Paradigm/Macroscopic_CCR97.pdf The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm]
<br>
<br>
<br>

===Articoli, Esercitazioni, Temi d'Anno===

== 2018 ==
<absHTML>
<a href="https://docs.google.com/document/d/e/2PACX-1vTt0LiqCPdNUbanzhq6QBen9-QyxomWhy7p9s9WtZKLQfvd9JdAz6s9avIszxsFqh7RfxZTsdPdyVoz/pub">Link</a>
<iframe src="https://docs.google.com/document/d/e/2PACX-1vTt0LiqCPdNUbanzhq6QBen9-QyxomWhy7p9s9WtZKLQfvd9JdAz6s9avIszxsFqh7RfxZTsdPdyVoz/pub?embedded=true" frameborder="0" marginwidth="0" style="width: 100%; min-height: 400px;"></iframe>
</absHTML>

===2017===
* [https://docs.google.com/presentation/d/e/2PACX-1vROaO7j6c7UlYf64pn6s7jmscSvDefSqpojibOLhwXr5Renk4wMtjE6WybpBGAt4iJvtHhApi6tBYEM/pub?start=false&loop=false&delayms=60000 Introduction to Docker and Kubernetes]
* [https://docs.google.com/presentation/d/e/2PACX-1vSo4MzpE_NksEWUP4bxfL_ltoLvc_zc3Cea82IN-XBA59vz3jfTyXStJb3ttsF3cQGjcShQZYPJQZtK/pub?start=false&loop=false&delayms=3000 Introduction to VR and AR programming]

===2016===
* Comunicazione real-time con WebRTC ([[Media:webrtc-metoditlc-decicco.pdf | Slides ]])

====2015====
* Realizzazione di un osservatore di stato basato su filtro di Kalman per la stima della capacità del canale di trasmissione. Contattare [http://c3lab.poliba.it/index.php?title=GaetanoCarlucci Gaetano Carlucci ] per ricevere il materiale necessario.
* Studio di sistemi di video streaming DASH/HLS utilizzando HTTP2 o QUIC volto alla riduzione del delay utilizzando [https://github.com/ldecicco/tapas TAPAS ]
* Progettazione di un controllore per l’ adattamento del bitrate in un sistema di video streaming adattativo DASH/HLS utilizzando [https://github.com/ldecicco/tapas TAPAS ] - Documentazione: [https://github.com/ldecicco/tapas/tree/master/docs/sphinx Tapas documentation]
* Implementazione di un testbed SDN emulato mediante [http://mininet.org/ mininet] per realizzare un piano di controllo per una piattaforma di video streaming adattativo - Documentazione: [http://mininet.org/walkthrough/ mininet walkthrough ]
* Stabilizzazione dei movimenti di un visore stereoscopico. Link utili: [http://threejs.org/examples/#webgl_video_panorama_equirectangular Threejs demo]
* Trasmissione sicura tra laptop usando oscillatori caotici. Link utili: [ ]

====2014====

* [http://pv2013.itec.aau.at/wp-content/uploads/2013/12/Gaedtke.pdf QoE in Large-Scale Video Networks]

====2013====
* [http://tech.ebu.ch/docs/events/webinar043-mpeg-dash/presentations/ebu_mpeg-dash_webinar043.pdf MPEG's Dynamic Adaptive Streaming over HTTP (DASH) - Enabling Formats for Video Streaming over the Open Internet]
* [http://issuu.com/andruby/docs/http_live_streaming_presentatino HTTP Live Streaming presentation]
* [http://brettviren.github.io/pygst-tutorial-org/pygst-tutorial.pdf Python GStreamer tutorial]
* [[Media:python_web.pdf | Programmazione di rete con Python: le librerie Django e Twisted]],
* [https://docs.google.com/presentation/d/14w2U1Pp5GLLgGbtSHfzisHhenjDPqccxwfgCLu41KKM/pub?start=false&loop=false&delayms=3000 Esercitazione su GStreamer]

====2007====
* [[Media:net_testing.pdf | Linux Network Testing: Introduzione agli strumenti per il testing di rete su Linux (6,13 Novembre 2007)]], [http://c3lab.poliba.it/downloads/mdc/net_testing_examples.tar.bz2 sorgenti degli esempi ]
* Pacchetti Debian per [http://www.web100.org/ Web100]:
** Immagine del kernel 2.6.22: [http://c3lab.poliba.it/downloads/mdc/linux-image-2.6.22-web100_1_i386.deb linux-image-2.6.22-web100_1_i386.deb]
** Userspace utility: [http://c3lab.poliba.it/downloads/mdc/web100-userland_1.6-1_i386.deb web100-userland_1.6-1_i386.deb]
* [[Media:linux_kernel_intro.pdf | Linux Kernel: introduzione, kernel modules e infrastruttura del Congestion Control (23,30 Ottobre 2007)]], [http://c3lab.poliba.it/downloads/mdc/linux_kernel_examples.tar.bz2 sorgenti degli esempi ]

====2006====
* [[LorenzLab | Laboratorio del 3/02/06]]: Script in matlab sull'attrattore di Lorenz

== Temi di esame ==
* [[Media:metodi_01.pdf | Esame del 27-02-2008]]
* [[Media:metodi_02.pdf | Esame del 14-02-2011]]
* [[Media:metodi_03.pdf | Esame del 05-05-2011]]

== Temi d'anno ==

=== Testing comparativo di TCP Stacks ===
L'obiettivo è lo studio delle performance dei diversi TCP Stacks disponibili sui seguenti sistemi operativi:

*Linux 2.6.x
*Linux 2.4.x
*FreeBSD
*NetBSD
*Windows XP

Lo studente dovrà utilizzare applicazioni per l'auditing di reti e deve avere un background minimo sull'utilizzo di sistemi operativi GNU/Linux.

'''Riferimenti'''<br />
*[http://www.web100.org/ Web100 website]
*[http://www.netkit.org/ NetKit]
*[http://www.faqs.org/rfcs/rfc793.html Transmission Control Protocol RFC]
*[[Westwood | TCP Westwood+]]
*[http://netlab.caltech.edu/FAST/ FAST TCP]

Loren

2024-02-09T14:51:19Z

CarloCroce:

[[Category:Projects]]


[[File:LOGO_LOREN.png|250px]]

== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

File:LOGO LOREN.png

2024-02-09T14:50:50Z

CarloCroce:

Loren

2024-02-09T14:50:14Z

CarloCroce:

[[Category:Projects]]


[[File:LOGO_LOREN.png|400px]]

== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

Bootstrap:Subnav

2024-02-09T13:07:45Z

CarloCroce:

* [[C3Lab|Home]]
* [[Mascolo|Prof. Saverio Mascolo]]
* [[People]]
** [[LDC:Home|Luca De Cicco]]
** [[GioacchinoManfredi|Gioacchino Manfredi]]
** [[GiuseppeRibezzo|Giuseppe Ribezzo]]
** [[VitoRacanelli| Vito Andrea Racanelli]]
** [[CarloCroce|Carlo Croce]]
** [[WalterBrescia|Walter Brescia]]
** [[GiovanniTravaglio|Giovanni Travaglio]]
** [[Alumni]]
* Projects
** [[Loren| Loren]]
* Research
** [[Low_delay_communication| Low Delay Protocols]]
** [[HTTP_OVER_UDP| Reducing HTTP latency with QUIC]]
** [[MultimediaCC|Congestion Control for Real-time applications (WebRTC)]]
** [[Adaptive_Live_Video_Streaming|Adaptive Live Video Streaming]]
** [[TCP_over_Hsdpa|TCP over HSDPA]]
** [[Westwood|TCP Westwood+]]

* News
** [[News]]
** [[Awards]]

* [[Publications]]

* [[Collaborations]]

* [[Teaching]]
** [[Students]]
** [[Esami]]
** [[Courses]]

* [[ArgomentiTesi|Tesi]]

Bootstrap:Subnav

2024-02-09T13:07:11Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T11:49:19Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T11:49:08Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T11:48:56Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T11:31:28Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T11:31:08Z

CarloCroce:

Loren

2024-02-09T11:26:12Z

CarloCroce:

[[Category:Projects]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

Loren

2024-02-09T11:25:44Z

CarloCroce:

[[Category:Projects]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, Università degli Studi di Roma "La Sapienza", [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, Università degli Studi di Roma "La Sapienza", [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

File:LOGO italiadomani.jpg

2024-02-09T11:24:18Z

CarloCroce: Carlocroce ha caricato una nuova versione di File:LOGO italiadomani.jpg.

File:LOGO italiadomani.jpg

2024-02-09T11:23:38Z

CarloCroce: Carlocroce ha caricato una nuova versione di File:LOGO italiadomani.jpg.

Loren

2024-02-09T11:14:51Z

CarloCroce:

[[Category:Projects]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, Politecnico di Bari, [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, Politecnico di Bari, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

Loren

2024-02-09T11:13:54Z

CarloCroce:

[[Category:Projects]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px|center]]
<br>
[[File:LOGO_UniversitaRicerca.jpg|400px|center]]

[[File:LOGO_italiadomani.jpg|600px|center]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''People''' ==

{{Panel|type=primary|icon=graduation-cap|title=Politecnico di Bari|body=
Saverio Mascolo, Professore Ordinario, [https://c3lab.poliba.it/index.php?title=Mascolo Website]
Luca De Cicco, Professore Associato, [https://c3lab.poliba.it/index.php?title=LDC:Home Website]
}}

{{Panel|type=primary|icon=graduation-cap|title=Università degli Studi di Roma "La Sapienza"|body=
Andrea Baiocchi, Professore Ordinario, Politecnico di Bari, [https://corsidilaurea.uniroma1.it/it/users/andreabaiocchiuniroma1it Website]
Davide Aureli, Dottorando, Politecnico di Bari, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
}}


----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

The schematic of the filter and of the congestion control algorithm is shown in the figure below.

[[File:schematic-filter-process-congestion-controlloop.png|center|800px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change with respect to the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the following figure.

[[File:Google-Congestion-Control-architecture.png|center|800px]]

File:LOGO italiadomani.jpg

2024-02-09T11:11:41Z

CarloCroce: Carlocroce ha caricato una nuova versione di File:LOGO italiadomani.jpg.

File:LOGO italiadomani.jpg

2024-02-09T11:08:24Z

CarloCroce:

Loren

2024-02-09T11:05:12Z

CarloCroce:

MediaWiki:Sidebar

2024-02-09T10:10:13Z

CarloCroce:

Loren

2024-02-08T18:43:18Z

CarloCroce:

[[Category:Research]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px]][[File:LOGO_UniversitaRicerca.jpg|400px]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google, aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control.

----

== '''End-to-end low-delay congestion control''' ==
Differently, from what has been proposed in the literature, the congestion control algorithm will be rigorously designed based on feedback control theory in order to guarantee properties such as stability, robustness, and speed of convergence.
The proposed algorithms will be tested in laboratory as well as in production networks. In particular, we will access the testing capabilities provided by Google which allow experimenting with new congestion control algorithms in the browsers.
This activity is made possible by leveraging our consolidated research collaboration with Google which allows us to experiment in the wild on a large population of Google Chrome users. Moreover, we will test the proposed algorithms in a 5G testbed in collaboration with prof. Alay Ozgu at the Department of Informatics at the University of Oslo where she leads the Gemini IoT Center and is involved in building a 5G and IoT testbed through 5GENESIS EU project.

We will consider different control architectures where the congestion control algorithm is placed at the sender, or at the receiver or hybrid, i.e. in part at the sender and in part at the receiver.
For control algorithms closed over the Internet and for which it is not possible to avoid relevant delayed feedback, robust controllers with modified Smith predictor will be considered.
In the case of real-time (i.e. delay-sensitive) flows, the key issue resides in the fact that not only congestion avoidance but also control of network queue lengths are required to limit delays. The idea is to exploit packet delay measurements for feedback.
We will consider the one-way delay variation d_i and the packet Inter-Arrival Time (IAT) at the receiver, IAT_i = t_i – t_{i-1}, that can be measured as shown in the figure below, where T_i represents the time at which the i-th packet has been sent and t_i is the time at which the packet has been received (T_i is timestamped in the packet). It is very important to note that this end-to-end measurement can be easily executed and represents a solid starting point to establish a feedback-based control of connection delays.

[[File:one-way-delay-variation-measurement.png|center|500px]]

An increase of the one-way delay variation, or jitter, indicates that queueing delay along the forward communication path is increasing due to queues being filled which in turn are a sign of the onset of network congestion.
One-way delay variation measurements are promising for queuing control since they avoid the “latecomer effect” and sensitivity to the reverse-path traffic. Measuring IAT variations at the sender is an extremely quick method to estimate the bandwidth available at the bottleneck and also the bottleneck capacity.
The measurement of delay variations experienced by packets traveling from a sender to a receiver is challenging due to the fact that one-way delay variations are affected by unknown packets processing times and, in the case of wireless links, by lower layer retransmissions that can be modeled as noise. Statistical characterization of the noise will be carried out in different scenarios such as wired and mobile networks. Then, based on such statistical characterization, we will investigate and compare approaches to filter out the network noise such as a Kalman filter. In the case of data center networks, it has been shown that delay gradient measurements can be done in network interface cards.
The Figure below shows a schematic of the filter and of the congestion control algorithm.

[[File:schematic-filter-process-congestion-controlloop.png|center|500px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate. This will be a major change wrt the current implementation of the Google Congestion Control (GCC) where the congestion control is driven by the state machine at the receiver shown in the figure below, within the complete architecture.

[[File:finite-state-machine-remote-rate-controller.png|center|500px]]

In detail, a GCC flow is controlled at the sender by a Multiplicative Increase Multiplicative Decrease (MIMD) loss-based algorithm and at the receiver by a delay-based algorithm that measures and compares the one-way queuing time variation m_i with a threshold g_i.
The sending rate is set as the minimum of the rates computed by these controllers which are respectively A_s and A_r. At the receiver, the remote rate controller is the finite state machine shown in the figure above in which the state is changed by the signal s_i produced by the over-use detector that is fed by the output of the arrival-time filter, which estimates m_i. The FSM is used to compute A_r . The REMB Processing sends REMB messages containing A_r to the Sender.
The figure below shows that a GCC flow using a constant threshold gets starved when a concurrent TCP flow starts. We have found that starvation also occurs when two coexisting GCC flows share a bottleneck.

[[File:Fairness-issues-Google-Congestion-Control.png|center|1000px]]

To overcome these issues, we have proposed the following adaptive threshold g_i to be used by the over-use detector [Car17, Hol15]:

[[File:adaptive-threshold.png|center|300px]]

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

[[File:Effect-adaptive-threshold.png|center|800px]]

However, this algorithm still exhibits several issues. One issue is that the sending rate tracks a time-varying channel capacity with a large settling time. As an example, the figure below shows that the sending rate takes more than 20 seconds to track the link capacity after that it is increased at t=40s.

[[File:Sending-rate-case-variable-link-capacity.png|center|500px]]

Moreover, the following state space and output equations describing the one-way delay variations lack observability in some conditions:

[[File:state-space-output-equation.png|center|400px]]

where:
* C_i is the link capacity;
* m_i is the one-way queuing delay variation;
* d_i is the the total one-way delay variation;
* DL_i is the variation of two consecutive video frames size.

The complex non-linear interacting control equations governing a GCC flow make it impossible to get a rigorous mathematical proof of properties such as stability and rate of convergence. In view of this issue, an important goal will be to design a congestion control algorithm so that a mathematically tractable controlled system is obtained and key properties, such as stability, convergence rate, and observability can be proven.
The proposed theoretical framework could be leveraged by researchers to design and analyze congestion control algorithms for real-time flows. It will also pave the way for new studies focusing on the interplay between congestion control algorithms placed at the end-points and control functionalities placed in the networks such as AQM and, more interestingly, in SDN switches. In particular, the interplay between end-to-end delay-based congestion control algorithms and dynamic bandwidth allocation algorithms in SDN switches (f.i., implementing network slicing) is a fundamental research issue that has not been explored.
Moreover, the research carried out in this project may contribute to the design of methods for robust control of time-delay systems and to the design of techniques for estimating the one-way delay variation experienced by packets traveling over the Internet.

----

== '''Cooperation between e2e congestion control and in-network control functionalities''' ==

The second line of development for the proposed algorithms is aimed at the specific context of broadband cellular networks. The main idea we intend to investigate is related to introducing a proxy at the edge of the cellular network to help exploit the variable capacity of the wireless link, without inducing wild variations of TCP congestion window, hence instability of the connection and large delay variations, which has been pointed at as a potential issue of current congestion control approach in relation with 5G networks.

We assume that cross-layer functions can be devised at the edge so that the wireless channel capacity resulting from the complex interplay of radio propagation, modulation and coding, multiple access, and scheduling can be monitored and possibly predicted.
The proxy at the edge plays the role of an adaptive flow controller that modulates the advertised window signaled back to the remote TCP data source so as to maintain low queueing delay at the connection bottleneck while utilizing the available capacity efficiently.
A scheme of the envisaged control architecture is depicted in the following figure:

[[File:Proxy-based-control-arch-cellular-network.png|center|500px]]

The main idea is to move the receiver-side algorithms developed in the first part of the project and described in the first part of this section to the proxy.
Split TCP approaches have been already proposed and investigated and experimented. The novelty we intend to introduce is as follows: (i) focusing on low delay traffic, hence maintaining low queueing delay at the bottleneck; (ii) introducing a proxy-side estimation algorithm for jitter and IAT; (iii) exploiting the advertised window to drive congestion control acting from the proxy.

The proxy-side algorithm workflow can be concisely stated as follows:
* Phase 1 (initialization): estimate the pipe capacity and current utilization of the pipe.
* Phase 2 (probing): increase the advertised window and check whether the sender matches it.
* Phase 3 (adaptation): tracking of available capacity.

Preliminary results of the time evolution of the throughput maintained by four TCP connections sharing the same bottleneck are
shown in the following figure. It is to be stressed that the almost full and fair utilization of the bottleneck bandwidth is achieved while
maintaining the bottleneck buffer essentially empty.

[[File:Throughput-with-proxy-based-congestion-control.png|center|700px]]

We plan to apply the rigorous control-theoretical framework developed in the first part of this project to this proxy-based approach and then extend the performance evaluation, both by means of ns-3 based simulations and experiments, to several interesting scenarios (e.g., different RTT values, asymmetric traffic, competition with legacy congestion control flows).

Finally, we plan to evaluate the potential of in-band network telemetry (INT) functionality to support low-delay congestion control in the same framework outlined above. INT could provide detailed additional information on the congestion status of the connection path, thus helping to refine the control accuracy besides estimates of IAT and variation of IAT at the receiver.

== '''Performance evaluation methodology''' ==

A set of requirements will be defined by taking into account the IETF RMCAT WG recommendations [RFC8836] such as low delays, intra- and inter-protocol fairness.
The proposed congestion control algorithm will be implemented in the open-source Chromium web browser. The performance evaluation will be carried out in two phases: at first, the control will be experimented in a laboratory testbed. By using tools to emulate a Wide Area Network, repeatable experiments will be executed. In the second phase, the algorithm will be tested on the real Internet browser and accessing a 5G station. In setting up test scenarios we will also refer to [RFC8869].
The experiments in the controlled testbed will consider the scenarios defined at IETF in [RFC8867].
The figure below shows an example of the architecture of the envisaged controlled testbed to be used in the project.

[[File:controlled-testbed-architecture.png|center|500px]]

In this phase, we will also compare the proposed congestion control algorithm with other solutions proposed at the IETF RMCAT WG such as, f.i., NADA by Cisco and SCREAM by Ericsson. Recent proposals will also be considered.

In the second phase, thanks to our active collaboration with Google, we will be able to experiment with the proposed algorithm on a large set of Google Chrome users, who employ WebRTC to establish video-conferencing sessions. This will produce a large experimental dataset that we aim at releasing.
Moreover, we will test the proposed algorithm in the 5Genensis EU testbed [https://5genesis.eu/] and in the UiO’s Sustainable Immersive Networking Lab (SIN-Lab) both located at the University of Oslo under the responsibility of prof. Alay Ozgu. 5Genensis is a 5G testbed and SIN-Lab is a playground for immersive networking research that focuses on providing a true sensation of presence in a remote location through haptic interaction. It consists of 5G equipment, multimedia equipment, and haptics equipment. In terms of 5G/B5G, it offers two powerful SDRs (USRP N310) to run a 5G/B5G RAN and UE with open source software such as Open Air Interface.
Furthermore, it makes available user equipment that supports multi-connectivity of 4G, 5G and Wifi, along with a set of 5G phones.
For the multimedia equipment, SIN-Lab consists of state of the art cameras and LIDARs, Intel RealSense Tracking Camera (T265), Velodyne LIDAR (VLP-16), Intel RealSense LIDAR (L515), Azure Kinect and several headsets for VR (HTC Vive, Oculus Rift, several Oculus Quest2) and AR (Microsoft Hololens, Project Northstar). For the haptics equipment, SIN-Lab has several wearable devices such as StretchSense Haptic Gloves (with motion capture), Prime X Haptic VR (including gloves with haptic feedback), Forte Data Gloves, Ultrahaptics Stratos (in-air touch feedback) and BHaptics Full Body Suit (with 40 motors providing haptic feedback on the human torso).

Finally, the proposed algorithm will be experimented in autonomous navigation scenarios using the Mobile Robotics and Embedded Control (MOBIREC) laboratory at Politecnico di Bari where several mobile robots are available and a VICON tracking system composed of 8 Vero cameras is available. In this scenario, the VICON tracking system will accurately and continuously estimate the position of the mobile robots present in an arena measuring approximately 40 square meters and the proposed algorithm will be used to stream data to the robots in real-time. The estimated pose will be used by the robots to form a closed-loop control system for autonomous navigation.

Loren

2024-02-08T18:38:18Z

CarloCroce:

[[Category:Research]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px]][[File:LOGO_UniversitaRicerca.jpg|400px]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google [Car17], aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control [Zha19].

----

== '''End-to-end low-delay congestion control''' ==
Differently, from what has been proposed in the literature, the congestion control algorithm will be rigorously designed based on feedback control theory in order to guarantee properties such as stability, robustness, and speed of convergence.
The proposed algorithms will be tested in laboratory as well as in production networks. In particular, we will access the testing capabilities provided by Google which allow experimenting with new congestion control algorithms in the browsers.
This activity is made possible by leveraging our consolidated research collaboration with Google which allows us to experiment in the wild on a large population of Google Chrome users. Moreover, we will test the proposed algorithms in a 5G testbed in collaboration with prof. Alay Ozgu at the Department of Informatics at the University of Oslo where she leads the Gemini IoT Center and is involved in building a 5G and IoT testbed through 5GENESIS EU project.

We will consider different control architectures where the congestion control algorithm is placed at the sender, or at the receiver or hybrid, i.e. in part at the sender and in part at the receiver.
For control algorithms closed over the Internet and for which it is not possible to avoid relevant delayed feedback, robust controllers with modified Smith predictor will be considered [Mas99],[DeC11].
In the case of real-time (i.e. delay-sensitive) flows, the key issue resides in the fact that not only congestion avoidance but also control of network queue lengths are required to limit delays. The idea is to exploit packet delay measurements for feedback.
We will consider the one-way delay variation d_i and the packet Inter-Arrival Time (IAT) at the receiver, IAT_i = t_i – t_{i-1}, that can be measured as shown in the figure below, where T_i represents the time at which the i-th packet has been sent and t_i is the time at which the packet has been received (T_i is timestamped in the packet). It is very important to note that this end-to-end measurement can be easily executed and represents a solid starting point to establish a feedback-based control of connection delays.

[[File:one-way-delay-variation-measurement.png|center|500px]]

An increase of the one-way delay variation, or jitter, indicates that queueing delay along the forward communication path is increasing due to queues being filled which in turn are a sign of the onset of network congestion.
One-way delay variation measurements are promising for queuing control since they avoid the “latecomer effect” [Car10] and sensitivity to the reverse-path traffic [Mas06]. Measuring IAT variations at the sender is an extremely quick method to estimate the bandwidth available at the bottleneck and also the bottleneck capacity.
The measurement of delay variations experienced by packets traveling from a sender to a receiver is challenging due to the fact that one-way delay variations are affected by unknown packets processing times and, in the case of wireless links, by lower layer retransmissions that can be modeled as noise. Statistical characterization of the noise will be carried out in different scenarios such as wired and mobile networks. Then, based on such statistical characterization, we will investigate and compare approaches to filter out the network noise such as a Kalman filter. In the case of data center networks, it has been shown that delay gradient measurements can be done in network interface cards [Mit15].
The Figure below shows a schematic of the filter and of the congestion control algorithm.

[[File:schematic-filter-process-congestion-controlloop.png|center|500px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate [Gri04]. This will be a major change wrt the current implementation of the Google Congestion Control (GCC) [Car17] where the congestion control is driven by the state machine at the receiver shown in the figure below, within the complete architecture.

[[File:finite-state-machine-remote-rate-controller.png|center|500px]]

In detail, a GCC flow is controlled at the sender by a Multiplicative Increase Multiplicative Decrease (MIMD) loss-based algorithm and at the receiver by a delay-based algorithm that measures and compares the one-way queuing time variation m_i with a threshold g_i.
The sending rate is set as the minimum of the rates computed by these controllers which are respectively A_s and A_r. At the receiver, the remote rate controller is the finite state machine shown in the figure above in which the state is changed by the signal s_i produced by the over-use detector that is fed by the output of the arrival-time filter, which estimates m_i. The FSM is used to compute A_r . The REMB Processing sends REMB messages containing A_r to the Sender.
The figure below shows that a GCC flow using a constant threshold gets starved when a concurrent TCP flow starts. We have found that starvation also occurs when two coexisting GCC flows share a bottleneck [Pav13].

[[File:Fairness-issues-Google-Congestion-Control.png|center|1000px]]

To overcome these issues, we have proposed the following adaptive threshold g_i to be used by the over-use detector [Car17, Hol15]:

[[File:adaptive-threshold.png|center|300px]]

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

[[File:Effect-adaptive-threshold.png|center|800px]]

However, this algorithm still exhibits several issues. One issue is that the sending rate tracks a time-varying channel capacity with a large settling time. As an example, the figure below shows that the sending rate takes more than 20 seconds to track the link capacity after that it is increased at t=40s.

[[File:Sending-rate-case-variable-link-capacity.png|center|500px]]

Moreover, the following state space and output equations describing the one-way delay variations lack observability in some conditions:

[[File:state-space-output-equation.png|center|400px]]

where:
* C_i is the link capacity;
* m_i is the one-way queuing delay variation;
* d_i is the the total one-way delay variation;
* DL_i is the variation of two consecutive video frames size.

The complex non-linear interacting control equations governing a GCC flow make it impossible to get a rigorous mathematical proof of properties such as stability and rate of convergence. In view of this issue, an important goal will be to design a congestion control algorithm so that a mathematically tractable controlled system is obtained and key properties, such as stability, convergence rate, and observability can be proven.
The proposed theoretical framework could be leveraged by researchers to design and analyze congestion control algorithms for real-time flows. It will also pave the way for new studies focusing on the interplay between congestion control algorithms placed at the end-points and control functionalities placed in the networks such as AQM and, more interestingly, in SDN switches. In particular, the interplay between end-to-end delay-based congestion control algorithms and dynamic bandwidth allocation algorithms in SDN switches (f.i., implementing network slicing) is a fundamental research issue that has not been explored.
Moreover, the research carried out in this project may contribute to the design of methods for robust control of time-delay systems and to the design of techniques for estimating the one-way delay variation experienced by packets traveling over the Internet.

----

== '''Cooperation between e2e congestion control and in-network control functionalities''' ==

The second line of development for the proposed algorithms is aimed at the specific context of broadband cellular networks. The main idea we intend to investigate is related to introducing a proxy at the edge of the cellular network to help exploit the variable capacity of the wireless link, without inducing wild variations of TCP congestion window, hence instability of the connection and large delay variations, which has been pointed at as a potential issue of current congestion control approach in relation with 5G networks[Zha19].

We assume that cross-layer functions can be devised at the edge so that the wireless channel capacity resulting from the complex interplay of radio propagation, modulation and coding, multiple access, and scheduling can be monitored and possibly predicted.
The proxy at the edge plays the role of an adaptive flow controller that modulates the advertised window signaled back to the remote TCP data source so as to maintain low queueing delay at the connection bottleneck while utilizing the available capacity efficiently.
A scheme of the envisaged control architecture is depicted in the following figure:

[[File:Proxy-based-control-arch-cellular-network.png|center|500px]]

The main idea is to move the receiver-side algorithms developed in the first part of the project and described in the first part of this section to the proxy.
Split TCP approaches have been already proposed and investigated and experimented [Kop02][LeW16]. The novelty we intend to introduce is as follows: (i) focusing on low delay traffic, hence maintaining low queueing delay at the bottleneck; (ii) introducing a proxy-side estimation algorithm for jitter and IAT; (iii) exploiting the advertised window to drive congestion control acting from the proxy.

The proxy-side algorithm workflow can be concisely stated as follows:
* Phase 1 (initialization): estimate the pipe capacity and current utilization of the pipe.
* Phase 2 (probing): increase the advertised window and check whether the sender matches it.
* Phase 3 (adaptation): tracking of available capacity.

Preliminary results of the time evolution of the throughput maintained by four TCP connections sharing the same bottleneck are
shown in the following figure. It is to be stressed that the almost full and fair utilization of the bottleneck bandwidth is achieved while
maintaining the bottleneck buffer essentially empty.

[[File:Throughput-with-proxy-based-congestion-control.png|center|700px]]

We plan to apply the rigorous control-theoretical framework developed in the first part of this project to this proxy-based approach and then extend the performance evaluation, both by means of ns-3 based simulations and experiments, to several interesting scenarios (e.g., different RTT values, asymmetric traffic, competition with legacy congestion control flows).

Finally, we plan to evaluate the potential of in-band network telemetry (INT) functionality to support low-delay congestion control in the same framework outlined above. INT could provide detailed additional information on the congestion status of the connection path, thus helping to refine the control accuracy besides estimates of IAT and variation of IAT at the receiver. The effectiveness of INT, when properly supported by intermediate routers, has been investigated in data center environments in [LiY19].

== '''Performance evaluation methodology''' ==

A set of requirements will be defined by taking into account the IETF RMCAT WG recommendations [RFC8836] such as low delays, intra- and inter-protocol fairness.
The proposed congestion control algorithm will be implemented in the open-source Chromium web browser. The performance evaluation will be carried out in two phases: at first, the control will be experimented in a laboratory testbed. By using tools to emulate a Wide Area Network, repeatable experiments will be executed. In the second phase, the algorithm will be tested on the real Internet browser and accessing a 5G station. In setting up test scenarios we will also refer to [RFC8869].
The experiments in the controlled testbed will consider the scenarios defined at IETF in [RFC8867].
The figure below shows an example of the architecture of the envisaged controlled testbed to be used in the project.

[[File:controlled-testbed-architecture.png|center|500px]]

In this phase, we will also compare the proposed congestion control algorithm with other solutions proposed at the IETF RMCAT WG such as, f.i., NADA by Cisco [Zhu13] and SCREAM by Ericsson [Joh14]. Recent proposals will also be considered, [Aru18], [DONG18].

In the second phase, thanks to our active collaboration with Google, we will be able to experiment with the proposed algorithm on a large set of Google Chrome users, who employ WebRTC to establish video-conferencing sessions. This will produce a large experimental dataset that we aim at releasing.
Moreover, we will test the proposed algorithm in the 5Genensis EU testbed [https://5genesis.eu/] and in the UiO’s Sustainable Immersive Networking Lab (SIN-Lab) both located at the University of Oslo under the responsibility of prof. Alay Ozgu. 5Genensis is a 5G testbed and SIN-Lab is a playground for immersive networking research that focuses on providing a true sensation of presence in a remote location through haptic interaction. It consists of 5G equipment, multimedia equipment, and haptics equipment. In terms of 5G/B5G, it offers two powerful SDRs (USRP N310) to run a 5G/B5G RAN and UE with open source software such as Open Air Interface.
Furthermore, it makes available user equipment that supports multi-connectivity of 4G, 5G and Wifi, along with a set of 5G phones.
For the multimedia equipment, SIN-Lab consists of state of the art cameras and LIDARs, Intel RealSense Tracking Camera (T265), Velodyne LIDAR (VLP-16), Intel RealSense LIDAR (L515), Azure Kinect and several headsets for VR (HTC Vive, Oculus Rift, several Oculus Quest2) and AR (Microsoft Hololens, Project Northstar). For the haptics equipment, SIN-Lab has several wearable devices such as StretchSense Haptic Gloves (with motion capture), Prime X Haptic VR (including gloves with haptic feedback), Forte Data Gloves, Ultrahaptics Stratos (in-air touch feedback) and BHaptics Full Body Suit (with 40 motors providing haptic feedback on the human torso).

Finally, the proposed algorithm will be experimented in autonomous navigation scenarios using the Mobile Robotics and Embedded Control (MOBIREC) laboratory at Politecnico di Bari where several mobile robots are available and a VICON tracking system composed of 8 Vero cameras is available. In this scenario, the VICON tracking system will accurately and continuously estimate the position of the mobile robots present in an arena measuring approximately 40 square meters and the proposed algorithm will be used to stream data to the robots in real-time. The estimated pose will be used by the robots to form a closed-loop control system for autonomous navigation.

Loren

2024-02-08T18:37:12Z

CarloCroce:

[[Category:Research]]

= LOREN =
== LOw-delay congestion control for REal-time applications over the iNternet ==

[[File:LOGO_FinanziatoUnioneEuropea.png|500px]][[File:LOGO_UniversitaRicerca.jpg|500px]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google [Car17], aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control [Zha19].

----

== '''End-to-end low-delay congestion control''' ==
Differently, from what has been proposed in the literature, the congestion control algorithm will be rigorously designed based on feedback control theory in order to guarantee properties such as stability, robustness, and speed of convergence.
The proposed algorithms will be tested in laboratory as well as in production networks. In particular, we will access the testing capabilities provided by Google which allow experimenting with new congestion control algorithms in the browsers.
This activity is made possible by leveraging our consolidated research collaboration with Google which allows us to experiment in the wild on a large population of Google Chrome users. Moreover, we will test the proposed algorithms in a 5G testbed in collaboration with prof. Alay Ozgu at the Department of Informatics at the University of Oslo where she leads the Gemini IoT Center and is involved in building a 5G and IoT testbed through 5GENESIS EU project.

We will consider different control architectures where the congestion control algorithm is placed at the sender, or at the receiver or hybrid, i.e. in part at the sender and in part at the receiver.
For control algorithms closed over the Internet and for which it is not possible to avoid relevant delayed feedback, robust controllers with modified Smith predictor will be considered [Mas99],[DeC11].
In the case of real-time (i.e. delay-sensitive) flows, the key issue resides in the fact that not only congestion avoidance but also control of network queue lengths are required to limit delays. The idea is to exploit packet delay measurements for feedback.
We will consider the one-way delay variation d_i and the packet Inter-Arrival Time (IAT) at the receiver, IAT_i = t_i – t_{i-1}, that can be measured as shown in the figure below, where T_i represents the time at which the i-th packet has been sent and t_i is the time at which the packet has been received (T_i is timestamped in the packet). It is very important to note that this end-to-end measurement can be easily executed and represents a solid starting point to establish a feedback-based control of connection delays.

[[File:one-way-delay-variation-measurement.png|center|500px]]

An increase of the one-way delay variation, or jitter, indicates that queueing delay along the forward communication path is increasing due to queues being filled which in turn are a sign of the onset of network congestion.
One-way delay variation measurements are promising for queuing control since they avoid the “latecomer effect” [Car10] and sensitivity to the reverse-path traffic [Mas06]. Measuring IAT variations at the sender is an extremely quick method to estimate the bandwidth available at the bottleneck and also the bottleneck capacity.
The measurement of delay variations experienced by packets traveling from a sender to a receiver is challenging due to the fact that one-way delay variations are affected by unknown packets processing times and, in the case of wireless links, by lower layer retransmissions that can be modeled as noise. Statistical characterization of the noise will be carried out in different scenarios such as wired and mobile networks. Then, based on such statistical characterization, we will investigate and compare approaches to filter out the network noise such as a Kalman filter. In the case of data center networks, it has been shown that delay gradient measurements can be done in network interface cards [Mit15].
The Figure below shows a schematic of the filter and of the congestion control algorithm.

[[File:schematic-filter-process-congestion-controlloop.png|center|500px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate [Gri04]. This will be a major change wrt the current implementation of the Google Congestion Control (GCC) [Car17] where the congestion control is driven by the state machine at the receiver shown in the figure below, within the complete architecture.

[[File:finite-state-machine-remote-rate-controller.png|center|500px]]

In detail, a GCC flow is controlled at the sender by a Multiplicative Increase Multiplicative Decrease (MIMD) loss-based algorithm and at the receiver by a delay-based algorithm that measures and compares the one-way queuing time variation m_i with a threshold g_i.
The sending rate is set as the minimum of the rates computed by these controllers which are respectively A_s and A_r. At the receiver, the remote rate controller is the finite state machine shown in the figure above in which the state is changed by the signal s_i produced by the over-use detector that is fed by the output of the arrival-time filter, which estimates m_i. The FSM is used to compute A_r . The REMB Processing sends REMB messages containing A_r to the Sender.
The figure below shows that a GCC flow using a constant threshold gets starved when a concurrent TCP flow starts. We have found that starvation also occurs when two coexisting GCC flows share a bottleneck [Pav13].

[[File:Fairness-issues-Google-Congestion-Control.png|center|1000px]]

To overcome these issues, we have proposed the following adaptive threshold g_i to be used by the over-use detector [Car17, Hol15]:

[[File:adaptive-threshold.png|center|300px]]

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

[[File:Effect-adaptive-threshold.png|center|800px]]

However, this algorithm still exhibits several issues. One issue is that the sending rate tracks a time-varying channel capacity with a large settling time. As an example, the figure below shows that the sending rate takes more than 20 seconds to track the link capacity after that it is increased at t=40s.

[[File:Sending-rate-case-variable-link-capacity.png|center|500px]]

Moreover, the following state space and output equations describing the one-way delay variations lack observability in some conditions:

[[File:state-space-output-equation.png|center|400px]]

where:
* C_i is the link capacity;
* m_i is the one-way queuing delay variation;
* d_i is the the total one-way delay variation;
* DL_i is the variation of two consecutive video frames size.

The complex non-linear interacting control equations governing a GCC flow make it impossible to get a rigorous mathematical proof of properties such as stability and rate of convergence. In view of this issue, an important goal will be to design a congestion control algorithm so that a mathematically tractable controlled system is obtained and key properties, such as stability, convergence rate, and observability can be proven.
The proposed theoretical framework could be leveraged by researchers to design and analyze congestion control algorithms for real-time flows. It will also pave the way for new studies focusing on the interplay between congestion control algorithms placed at the end-points and control functionalities placed in the networks such as AQM and, more interestingly, in SDN switches. In particular, the interplay between end-to-end delay-based congestion control algorithms and dynamic bandwidth allocation algorithms in SDN switches (f.i., implementing network slicing) is a fundamental research issue that has not been explored.
Moreover, the research carried out in this project may contribute to the design of methods for robust control of time-delay systems and to the design of techniques for estimating the one-way delay variation experienced by packets traveling over the Internet.

----

== '''Cooperation between e2e congestion control and in-network control functionalities''' ==

The second line of development for the proposed algorithms is aimed at the specific context of broadband cellular networks. The main idea we intend to investigate is related to introducing a proxy at the edge of the cellular network to help exploit the variable capacity of the wireless link, without inducing wild variations of TCP congestion window, hence instability of the connection and large delay variations, which has been pointed at as a potential issue of current congestion control approach in relation with 5G networks[Zha19].

We assume that cross-layer functions can be devised at the edge so that the wireless channel capacity resulting from the complex interplay of radio propagation, modulation and coding, multiple access, and scheduling can be monitored and possibly predicted.
The proxy at the edge plays the role of an adaptive flow controller that modulates the advertised window signaled back to the remote TCP data source so as to maintain low queueing delay at the connection bottleneck while utilizing the available capacity efficiently.
A scheme of the envisaged control architecture is depicted in the following figure:

[[File:Proxy-based-control-arch-cellular-network.png|center|500px]]

The main idea is to move the receiver-side algorithms developed in the first part of the project and described in the first part of this section to the proxy.
Split TCP approaches have been already proposed and investigated and experimented [Kop02][LeW16]. The novelty we intend to introduce is as follows: (i) focusing on low delay traffic, hence maintaining low queueing delay at the bottleneck; (ii) introducing a proxy-side estimation algorithm for jitter and IAT; (iii) exploiting the advertised window to drive congestion control acting from the proxy.

The proxy-side algorithm workflow can be concisely stated as follows:
* Phase 1 (initialization): estimate the pipe capacity and current utilization of the pipe.
* Phase 2 (probing): increase the advertised window and check whether the sender matches it.
* Phase 3 (adaptation): tracking of available capacity.

Preliminary results of the time evolution of the throughput maintained by four TCP connections sharing the same bottleneck are
shown in the following figure. It is to be stressed that the almost full and fair utilization of the bottleneck bandwidth is achieved while
maintaining the bottleneck buffer essentially empty.

[[File:Throughput-with-proxy-based-congestion-control.png|center|700px]]

We plan to apply the rigorous control-theoretical framework developed in the first part of this project to this proxy-based approach and then extend the performance evaluation, both by means of ns-3 based simulations and experiments, to several interesting scenarios (e.g., different RTT values, asymmetric traffic, competition with legacy congestion control flows).

Finally, we plan to evaluate the potential of in-band network telemetry (INT) functionality to support low-delay congestion control in the same framework outlined above. INT could provide detailed additional information on the congestion status of the connection path, thus helping to refine the control accuracy besides estimates of IAT and variation of IAT at the receiver. The effectiveness of INT, when properly supported by intermediate routers, has been investigated in data center environments in [LiY19].

== '''Performance evaluation methodology''' ==

A set of requirements will be defined by taking into account the IETF RMCAT WG recommendations [RFC8836] such as low delays, intra- and inter-protocol fairness.
The proposed congestion control algorithm will be implemented in the open-source Chromium web browser. The performance evaluation will be carried out in two phases: at first, the control will be experimented in a laboratory testbed. By using tools to emulate a Wide Area Network, repeatable experiments will be executed. In the second phase, the algorithm will be tested on the real Internet browser and accessing a 5G station. In setting up test scenarios we will also refer to [RFC8869].
The experiments in the controlled testbed will consider the scenarios defined at IETF in [RFC8867].
The figure below shows an example of the architecture of the envisaged controlled testbed to be used in the project.

[[File:controlled-testbed-architecture.png|center|500px]]

In this phase, we will also compare the proposed congestion control algorithm with other solutions proposed at the IETF RMCAT WG such as, f.i., NADA by Cisco [Zhu13] and SCREAM by Ericsson [Joh14]. Recent proposals will also be considered, [Aru18], [DONG18].

In the second phase, thanks to our active collaboration with Google, we will be able to experiment with the proposed algorithm on a large set of Google Chrome users, who employ WebRTC to establish video-conferencing sessions. This will produce a large experimental dataset that we aim at releasing.
Moreover, we will test the proposed algorithm in the 5Genensis EU testbed [https://5genesis.eu/] and in the UiO’s Sustainable Immersive Networking Lab (SIN-Lab) both located at the University of Oslo under the responsibility of prof. Alay Ozgu. 5Genensis is a 5G testbed and SIN-Lab is a playground for immersive networking research that focuses on providing a true sensation of presence in a remote location through haptic interaction. It consists of 5G equipment, multimedia equipment, and haptics equipment. In terms of 5G/B5G, it offers two powerful SDRs (USRP N310) to run a 5G/B5G RAN and UE with open source software such as Open Air Interface.
Furthermore, it makes available user equipment that supports multi-connectivity of 4G, 5G and Wifi, along with a set of 5G phones.
For the multimedia equipment, SIN-Lab consists of state of the art cameras and LIDARs, Intel RealSense Tracking Camera (T265), Velodyne LIDAR (VLP-16), Intel RealSense LIDAR (L515), Azure Kinect and several headsets for VR (HTC Vive, Oculus Rift, several Oculus Quest2) and AR (Microsoft Hololens, Project Northstar). For the haptics equipment, SIN-Lab has several wearable devices such as StretchSense Haptic Gloves (with motion capture), Prime X Haptic VR (including gloves with haptic feedback), Forte Data Gloves, Ultrahaptics Stratos (in-air touch feedback) and BHaptics Full Body Suit (with 40 motors providing haptic feedback on the human torso).

Finally, the proposed algorithm will be experimented in autonomous navigation scenarios using the Mobile Robotics and Embedded Control (MOBIREC) laboratory at Politecnico di Bari where several mobile robots are available and a VICON tracking system composed of 8 Vero cameras is available. In this scenario, the VICON tracking system will accurately and continuously estimate the position of the mobile robots present in an arena measuring approximately 40 square meters and the proposed algorithm will be used to stream data to the robots in real-time. The estimated pose will be used by the robots to form a closed-loop control system for autonomous navigation.

Loren

2024-02-08T18:35:45Z

CarloCroce: Creata pagina con "Category:Research <center> <h1> LOREN </h1> <h2> LOw-delay congestion control for REal-time applications over the iNternet </h2> </center> File:LOGO_FinanziatoUn..."

[[Category:Research]]

<center>
<h1> LOREN </h1>
<h2> LOw-delay congestion control for REal-time applications over the iNternet </h2>
</center>

[[File:LOGO_FinanziatoUnioneEuropea.png|500px]][[File:LOGO_UniversitaRicerca.jpg|500px]]

== '''Description of the Project''' ==

Congestion control in packet networks has been historically focused on avoiding network overload while providing full network utilization. The cornerstone result was the well-known TCP congestion and flow control algorithm proposed by Van Jacobson.

The goal of this project is to propose an algorithm that not only avoids network congestion while providing high utilization but also controls the network delay. Controlling the delay is of the utmost importance since the Internet is not only aimed at delay insensitive data traffic, but also at real-time communications (i.e. video chat, live streaming, virtual reality) and real-time control (i.e. autonomous driving, telerobotics, telesurgery).

Starting from the state of the art, the first goal will be to design the fundamental functions of the algorithm using a rigorous theoretical approach based on control theory so that algorithm properties such as stability and efficiency can be mathematically proven. The algorithm will be designed by taking into account both well-behaving wired connections and the new and more challenging 5G networks that have shown the need for a more responsive congestion control algorithm. In fact, recent literature has shown that the 5G link introduces fast on-off connectivity periods that, due to the high 5G bandwidth and the TCP cyclic probing phases, lead to high retransmission rates when using classic TCP (i.e., NewReno, Cubic, BBR).

The algorithm will be designed in accordance with the end-to-end principle. However, feedback and control functions implemented or envisaged in current and evolving networks will be also considered, namely: Software Defined Networks (SDN) functionalities, that can be used for traffic engineering, e.g., to steer aggregate traffic flows according to load balancing principles; local cross-layer optimization in 5G/6G context, with highly variable links and smart scheduling algorithms in the lower layers; in-band network telemetry functionalities.

The second goal will be to investigate the trade-off of implementing the end-to-end algorithms at the application layer over UDP or at the transport layer (TCP over IP) depending on target applications. Implementation at the application layer has the advantage that different algorithms can be designed and tuned for specific classes of applications having different requirements of delays and responsiveness.

The third goal will be to carry out an extensive experimental evaluation in two scenarios: (a) production networks, by leveraging an established collaboration with researchers at Google [Car17], aiming at contributing to the development of the WebRTC standard used for videoconferencing; (b) autonomous driving where mobile robots need to communicate with the infrastructure (f.i. a tracking system) or between them by exchanging data and audio/video channels.

----

== '''Objectives and Methodologies''' ==
Over the past two decades, the Internet has evolved from being a data communication platform for the transport of data to a platform for real-time communications such as audio/video conferencing, streaming video, WebTV, online games, and real-time control.

Real-time flows, unlike data streams, pose stringent requirements both in terms of bitrate and maximum tolerable delay. The standard TCP congestion control has been designed to deliver greedy data streams with the goal of avoiding congestion while providing full link utilization. In fact, the TCP congestion control continuously probes for network available bandwidth through periodic cycles during which network queues are first filled and then drained. This behavior is not suitable for delivering delay-sensitive traffic. For this reason, video-conferencing applications implement their own congestion control and (optionally) data integrity protection functions at the application layer over the UDP, which does not implement congestion control and retransmissions.

The overall '''goal of this project is to design a congestion control algorithm for real-time flows''' as a key enabling technology for the real-time Internet.

On the application side, a specific focus will be devoted to 5G radio access. In fact, the large bandwidth promised by new radio access technologies (e.g., mmWave) and the volatility of this bandwidth poses a hard challenge to end-to-end congestion control [Zha19].

----

== '''End-to-end low-delay congestion control''' ==
Differently, from what has been proposed in the literature, the congestion control algorithm will be rigorously designed based on feedback control theory in order to guarantee properties such as stability, robustness, and speed of convergence.
The proposed algorithms will be tested in laboratory as well as in production networks. In particular, we will access the testing capabilities provided by Google which allow experimenting with new congestion control algorithms in the browsers.
This activity is made possible by leveraging our consolidated research collaboration with Google which allows us to experiment in the wild on a large population of Google Chrome users. Moreover, we will test the proposed algorithms in a 5G testbed in collaboration with prof. Alay Ozgu at the Department of Informatics at the University of Oslo where she leads the Gemini IoT Center and is involved in building a 5G and IoT testbed through 5GENESIS EU project.

We will consider different control architectures where the congestion control algorithm is placed at the sender, or at the receiver or hybrid, i.e. in part at the sender and in part at the receiver.
For control algorithms closed over the Internet and for which it is not possible to avoid relevant delayed feedback, robust controllers with modified Smith predictor will be considered [Mas99],[DeC11].
In the case of real-time (i.e. delay-sensitive) flows, the key issue resides in the fact that not only congestion avoidance but also control of network queue lengths are required to limit delays. The idea is to exploit packet delay measurements for feedback.
We will consider the one-way delay variation d_i and the packet Inter-Arrival Time (IAT) at the receiver, IAT_i = t_i – t_{i-1}, that can be measured as shown in the figure below, where T_i represents the time at which the i-th packet has been sent and t_i is the time at which the packet has been received (T_i is timestamped in the packet). It is very important to note that this end-to-end measurement can be easily executed and represents a solid starting point to establish a feedback-based control of connection delays.

[[File:one-way-delay-variation-measurement.png|center|500px]]

An increase of the one-way delay variation, or jitter, indicates that queueing delay along the forward communication path is increasing due to queues being filled which in turn are a sign of the onset of network congestion.
One-way delay variation measurements are promising for queuing control since they avoid the “latecomer effect” [Car10] and sensitivity to the reverse-path traffic [Mas06]. Measuring IAT variations at the sender is an extremely quick method to estimate the bandwidth available at the bottleneck and also the bottleneck capacity.
The measurement of delay variations experienced by packets traveling from a sender to a receiver is challenging due to the fact that one-way delay variations are affected by unknown packets processing times and, in the case of wireless links, by lower layer retransmissions that can be modeled as noise. Statistical characterization of the noise will be carried out in different scenarios such as wired and mobile networks. Then, based on such statistical characterization, we will investigate and compare approaches to filter out the network noise such as a Kalman filter. In the case of data center networks, it has been shown that delay gradient measurements can be done in network interface cards [Mit15].
The Figure below shows a schematic of the filter and of the congestion control algorithm.

[[File:schematic-filter-process-congestion-controlloop.png|center|500px]]

The estimated one-way delay variation will be used to feed a classic additive increase multiplicative decrease congestion control algorithm. When the estimated queueing delay gradient will reach a threshold, the congestion control algorithm will enter the multiplicative decrease phase or an adaptive decrease phase using an end-to-end bandwidth estimate [Gri04]. This will be a major change wrt the current implementation of the Google Congestion Control (GCC) [Car17] where the congestion control is driven by the state machine at the receiver shown in the figure below, within the complete architecture.

[[File:finite-state-machine-remote-rate-controller.png|center|500px]]

In detail, a GCC flow is controlled at the sender by a Multiplicative Increase Multiplicative Decrease (MIMD) loss-based algorithm and at the receiver by a delay-based algorithm that measures and compares the one-way queuing time variation m_i with a threshold g_i.
The sending rate is set as the minimum of the rates computed by these controllers which are respectively A_s and A_r. At the receiver, the remote rate controller is the finite state machine shown in the figure above in which the state is changed by the signal s_i produced by the over-use detector that is fed by the output of the arrival-time filter, which estimates m_i. The FSM is used to compute A_r . The REMB Processing sends REMB messages containing A_r to the Sender.
The figure below shows that a GCC flow using a constant threshold gets starved when a concurrent TCP flow starts. We have found that starvation also occurs when two coexisting GCC flows share a bottleneck [Pav13].

[[File:Fairness-issues-Google-Congestion-Control.png|center|1000px]]

To overcome these issues, we have proposed the following adaptive threshold g_i to be used by the over-use detector [Car17, Hol15]:

[[File:adaptive-threshold.png|center|300px]]

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

[[File:Effect-adaptive-threshold.png|center|800px]]

However, this algorithm still exhibits several issues. One issue is that the sending rate tracks a time-varying channel capacity with a large settling time. As an example, the figure below shows that the sending rate takes more than 20 seconds to track the link capacity after that it is increased at t=40s.

[[File:Sending-rate-case-variable-link-capacity.png|center|500px]]

Moreover, the following state space and output equations describing the one-way delay variations lack observability in some conditions:

[[File:state-space-output-equation.png|center|400px]]

where:
* C_i is the link capacity;
* m_i is the one-way queuing delay variation;
* d_i is the the total one-way delay variation;
* DL_i is the variation of two consecutive video frames size.

The complex non-linear interacting control equations governing a GCC flow make it impossible to get a rigorous mathematical proof of properties such as stability and rate of convergence. In view of this issue, an important goal will be to design a congestion control algorithm so that a mathematically tractable controlled system is obtained and key properties, such as stability, convergence rate, and observability can be proven.
The proposed theoretical framework could be leveraged by researchers to design and analyze congestion control algorithms for real-time flows. It will also pave the way for new studies focusing on the interplay between congestion control algorithms placed at the end-points and control functionalities placed in the networks such as AQM and, more interestingly, in SDN switches. In particular, the interplay between end-to-end delay-based congestion control algorithms and dynamic bandwidth allocation algorithms in SDN switches (f.i., implementing network slicing) is a fundamental research issue that has not been explored.
Moreover, the research carried out in this project may contribute to the design of methods for robust control of time-delay systems and to the design of techniques for estimating the one-way delay variation experienced by packets traveling over the Internet.

----

== '''Cooperation between e2e congestion control and in-network control functionalities''' ==

The second line of development for the proposed algorithms is aimed at the specific context of broadband cellular networks. The main idea we intend to investigate is related to introducing a proxy at the edge of the cellular network to help exploit the variable capacity of the wireless link, without inducing wild variations of TCP congestion window, hence instability of the connection and large delay variations, which has been pointed at as a potential issue of current congestion control approach in relation with 5G networks[Zha19].

We assume that cross-layer functions can be devised at the edge so that the wireless channel capacity resulting from the complex interplay of radio propagation, modulation and coding, multiple access, and scheduling can be monitored and possibly predicted.
The proxy at the edge plays the role of an adaptive flow controller that modulates the advertised window signaled back to the remote TCP data source so as to maintain low queueing delay at the connection bottleneck while utilizing the available capacity efficiently.
A scheme of the envisaged control architecture is depicted in the following figure:

[[File:Proxy-based-control-arch-cellular-network.png|center|500px]]

The main idea is to move the receiver-side algorithms developed in the first part of the project and described in the first part of this section to the proxy.
Split TCP approaches have been already proposed and investigated and experimented [Kop02][LeW16]. The novelty we intend to introduce is as follows: (i) focusing on low delay traffic, hence maintaining low queueing delay at the bottleneck; (ii) introducing a proxy-side estimation algorithm for jitter and IAT; (iii) exploiting the advertised window to drive congestion control acting from the proxy.

The proxy-side algorithm workflow can be concisely stated as follows:
* Phase 1 (initialization): estimate the pipe capacity and current utilization of the pipe.
* Phase 2 (probing): increase the advertised window and check whether the sender matches it.
* Phase 3 (adaptation): tracking of available capacity.

Preliminary results of the time evolution of the throughput maintained by four TCP connections sharing the same bottleneck are
shown in the following figure. It is to be stressed that the almost full and fair utilization of the bottleneck bandwidth is achieved while
maintaining the bottleneck buffer essentially empty.

[[File:Throughput-with-proxy-based-congestion-control.png|center|700px]]

We plan to apply the rigorous control-theoretical framework developed in the first part of this project to this proxy-based approach and then extend the performance evaluation, both by means of ns-3 based simulations and experiments, to several interesting scenarios (e.g., different RTT values, asymmetric traffic, competition with legacy congestion control flows).

Finally, we plan to evaluate the potential of in-band network telemetry (INT) functionality to support low-delay congestion control in the same framework outlined above. INT could provide detailed additional information on the congestion status of the connection path, thus helping to refine the control accuracy besides estimates of IAT and variation of IAT at the receiver. The effectiveness of INT, when properly supported by intermediate routers, has been investigated in data center environments in [LiY19].

== '''Performance evaluation methodology''' ==

A set of requirements will be defined by taking into account the IETF RMCAT WG recommendations [RFC8836] such as low delays, intra- and inter-protocol fairness.
The proposed congestion control algorithm will be implemented in the open-source Chromium web browser. The performance evaluation will be carried out in two phases: at first, the control will be experimented in a laboratory testbed. By using tools to emulate a Wide Area Network, repeatable experiments will be executed. In the second phase, the algorithm will be tested on the real Internet browser and accessing a 5G station. In setting up test scenarios we will also refer to [RFC8869].
The experiments in the controlled testbed will consider the scenarios defined at IETF in [RFC8867].
The figure below shows an example of the architecture of the envisaged controlled testbed to be used in the project.

[[File:controlled-testbed-architecture.png|center|500px]]

In this phase, we will also compare the proposed congestion control algorithm with other solutions proposed at the IETF RMCAT WG such as, f.i., NADA by Cisco [Zhu13] and SCREAM by Ericsson [Joh14]. Recent proposals will also be considered, [Aru18], [DONG18].

In the second phase, thanks to our active collaboration with Google, we will be able to experiment with the proposed algorithm on a large set of Google Chrome users, who employ WebRTC to establish video-conferencing sessions. This will produce a large experimental dataset that we aim at releasing.
Moreover, we will test the proposed algorithm in the 5Genensis EU testbed [https://5genesis.eu/] and in the UiO’s Sustainable Immersive Networking Lab (SIN-Lab) both located at the University of Oslo under the responsibility of prof. Alay Ozgu. 5Genensis is a 5G testbed and SIN-Lab is a playground for immersive networking research that focuses on providing a true sensation of presence in a remote location through haptic interaction. It consists of 5G equipment, multimedia equipment, and haptics equipment. In terms of 5G/B5G, it offers two powerful SDRs (USRP N310) to run a 5G/B5G RAN and UE with open source software such as Open Air Interface.
Furthermore, it makes available user equipment that supports multi-connectivity of 4G, 5G and Wifi, along with a set of 5G phones.
For the multimedia equipment, SIN-Lab consists of state of the art cameras and LIDARs, Intel RealSense Tracking Camera (T265), Velodyne LIDAR (VLP-16), Intel RealSense LIDAR (L515), Azure Kinect and several headsets for VR (HTC Vive, Oculus Rift, several Oculus Quest2) and AR (Microsoft Hololens, Project Northstar). For the haptics equipment, SIN-Lab has several wearable devices such as StretchSense Haptic Gloves (with motion capture), Prime X Haptic VR (including gloves with haptic feedback), Forte Data Gloves, Ultrahaptics Stratos (in-air touch feedback) and BHaptics Full Body Suit (with 40 motors providing haptic feedback on the human torso).

Finally, the proposed algorithm will be experimented in autonomous navigation scenarios using the Mobile Robotics and Embedded Control (MOBIREC) laboratory at Politecnico di Bari where several mobile robots are available and a VICON tracking system composed of 8 Vero cameras is available. In this scenario, the VICON tracking system will accurately and continuously estimate the position of the mobile robots present in an arena measuring approximately 40 square meters and the proposed algorithm will be used to stream data to the robots in real-time. The estimated pose will be used by the robots to form a closed-loop control system for autonomous navigation.

File:Throughput-with-proxy-based-congestion-control.png

2024-02-08T18:25:09Z

CarloCroce:

File:State-space-output-equation.png

2024-02-08T18:24:50Z

CarloCroce:

File:Sending-rate-case-variable-link-capacity.png

2024-02-08T18:24:32Z

CarloCroce:

File:Schematic-filter-process-congestion-controlloop.png

2024-02-08T18:24:12Z

CarloCroce:

File:Proxy-based-control-arch-cellular-network.png

2024-02-08T18:23:56Z

CarloCroce:

File:One-way-delay-variation-measurement.png

2024-02-08T18:23:33Z

CarloCroce:

File:Google-Congestion-Control-architecture.png

2024-02-08T18:23:06Z

CarloCroce:

File:Finite-state-machine-remote-rate-controller.png

2024-02-08T18:22:35Z

CarloCroce:

File:Fairness-issues-Google-Congestion-Control.png

2024-02-08T18:22:08Z

CarloCroce:

File:Effect-adaptive-threshold.png

2024-02-08T18:21:45Z

CarloCroce:

File:Controlled-testbed-architecture.png

2024-02-08T18:21:14Z

CarloCroce:

File:Adaptive-threshold.png

2024-02-08T18:20:51Z

CarloCroce:

File:LOGO UniversitaRicerca.jpg

2024-02-08T18:20:13Z

CarloCroce:

File:LOGO FinanziatoUnioneEuropea.png

2024-02-08T18:18:17Z

CarloCroce: