Loren - Cronologia

WalterBrescia il 10:48, 1 Lug 2024

2024-07-01T10:48:21Z

WalterBrescia il 10:48, 1 Lug 2024

2024-07-01T10:48:07Z

CarloCroce il 14:51, 9 Feb 2024

2024-02-09T14:51:19Z

CarloCroce il 14:50, 9 Feb 2024

2024-02-09T14:50:14Z

CarloCroce il 11:26, 9 Feb 2024

2024-02-09T11:26:12Z

CarloCroce il 11:25, 9 Feb 2024

2024-02-09T11:25:44Z

CarloCroce il 11:14, 9 Feb 2024

2024-02-09T11:14:51Z

CarloCroce il 11:13, 9 Feb 2024

2024-02-09T11:13:54Z

CarloCroce il 11:05, 9 Feb 2024

2024-02-09T11:05:12Z

Show changes

CarloCroce il 18:43, 8 Feb 2024

2024-02-08T18:43:18Z

←Older revision		Revisione 10:48, 1 Lug 2024
Riga 1:		Riga 1:
	[[Category:Projects]]		[[Category:Projects]]
−	~~[[Category:Research]]~~

	<!--- = LOREN = --->		<!--- = LOREN = --->

←Older revision		Revisione 10:48, 1 Lug 2024
Riga 1:		Riga 1:
	[[Category:Projects]]		[[Category:Projects]]
		+	[[Category:Research]]

	<!--- = LOREN = --->		<!--- = LOREN = --->

@@ Riga 2: / Riga 2: @@
 <!--- = LOREN = --->
-[[File:LOGO_LOREN.png|400px]]
+[[File:LOGO_LOREN.png|250px]]
 == LOw-delay congestion control for REal-time applications over the iNternet ==

@@ Riga 1: / Riga 1: @@
 [[Category:Projects]]
-= LOREN =
+<!--- = LOREN = --->
 == LOw-delay congestion control for REal-time applications over the iNternet ==

@@ Riga 55: / Riga 55: @@
 {{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]
+Andrea Baiocchi, Professore Ordinario, [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]
+Davide Aureli, Dottorando, [https://phd.uniroma1.it/web/DAVIDE-AURELI_nT1651051_IT.aspx Website]
 }}

@@ Riga 25: / Riga 25: @@
 ----
 == '''People''' ==
@@ Riga 50: / Riga 69: @@
 -->
 ----

@@ Riga 18: / Riga 18: @@
 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.
+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.
 ----
@@ Riga 29: / Riga 29: @@
 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].
+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.
 ----
@@ Riga 39: / Riga 39: @@
 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].
+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.
@@ Riga 46: / Riga 46: @@
 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.
+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 [Mit15].
+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 [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.
+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]]
@@ Riga 58: / Riga 58: @@
 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].
+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]]
@@ Riga 92: / Riga 92: @@
 == '''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].
+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.
@@ Riga 101: / Riga 101: @@
 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.
+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:
@@ Riga 116: / Riga 116: @@
 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].
+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''' ==
@@ Riga 127: / Riga 127: @@
 [[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 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.