Low delay communication - Cronologia

SMascolo il 13:10, 26 Gen 2017

2017-01-26T13:10:00Z

SMascolo: /* Bottleneck configuration */

2017-01-26T13:03:50Z

‎Bottleneck configuration

SMascolo il 12:59, 26 Gen 2017

2017-01-26T12:59:58Z

SMascolo il 12:47, 26 Gen 2017

2017-01-26T12:47:52Z

SMascolo: /* Real-time Video flow versus multiple TCP flows */

2017-01-26T12:46:04Z

‎Real-time Video flow versus multiple TCP flows

SMascolo: /* Real-time Video flow versus multiple TCP flows */

2017-01-26T12:45:46Z

‎Real-time Video flow versus multiple TCP flows

SMascolo: /* Real-time Video flow versus multiple TCP flows */

2017-01-26T12:45:24Z

‎Real-time Video flow versus multiple TCP flows

SMascolo: /* Real-time Video flow versus multiple TCP flows */

2017-01-26T12:44:54Z

‎Real-time Video flow versus multiple TCP flows

SMascolo: /* Real-time Video flow versus multiple TCP flows */

2017-01-26T12:24:19Z

‎Real-time Video flow versus multiple TCP flows

SMascolo: /* Real-time Video Flow in isolation */

2017-01-26T12:16:53Z

‎Real-time Video Flow in isolation

@@ Riga 89: / Riga 89: @@
 points, and several queuing disciplines employed at the bottleneck queue.
-== Real-time Video Flow in isolation ==
+=== Real-time Video Flow in isolation ===
 [[Immagine:single_flow.png|550px|center|''Single Flow'']]
@@ Riga 99: / Riga 99: @@
 Results show that if only real-time video traffic is considered, the end-to-end congestion control is able to contain the queuing delay with zero losses. On the other hand, PIE and CoDel provide roughly the same queuing delay of DropTail but with the drawback of introducing packet losses.
-== Real-time Video flow versus multiple TCP flows ==
+=== Real-time Video flow versus multiple TCP flows ===
 [[Immagine:vs_tcp.png|650px|center|''Vs TCP'']]

@@ Riga 42: / Riga 42: @@
 ! Value
 |-
-| DropTail (DT/300)
+| '''DropTail (DT/300)'''
 | style="text-align: center;" | queue size
 | style="text-align: center;" | 300 ms
 |-
-| rowspan="3"  style="vertical-align: middle;" | PIE
+| rowspan="3"  style="vertical-align: middle;" | '''PIE'''
 | style="text-align: center;" | t<sub>update</sub>
 | style="text-align: center;" | 30 ms
@@ Riga 57: / Riga 57: @@
 |-
 |-
-| rowspan="3"  style="vertical-align: middle;" | Codel
+| rowspan="3"  style="vertical-align: middle;" | '''Codel'''
 | style="text-align: center;" | interval
 | style="text-align: center;" | 100 ms
@@ Riga 68: / Riga 68: @@
 |-
 |-
-| SFQ (DT/300)
+| '''SFQ (DT/300)'''
 | style="text-align: center;" | queue size
 | style="text-align: center;" | 300 ms
 |-
-| rowspan="3"  style="vertical-align: middle;" | FQ Codel
+| rowspan="3"  style="vertical-align: middle;" | '''FQ Codel'''
 | style="text-align: center;" | interval
 | style="text-align: center;" | 100 ms

@@ Riga 1: / Riga 1: @@
 [[Category:Research]]
-=Controlling Queuing Delays for Low Delay Communication=
+= Low Delay Protocols =
 Delay sensitive applications require not only congestion control but also minimization of queuing delays to provide interactivity.

←Older revision		Revisione 12:47, 26 Gen 2017
Riga 114:		Riga 114:

	To get a further insight on the different behavior of GCC with SFQ or with Fq Codel in the presence of concurrent TCP traffic, Figure above compares the dynamics of rates, RTT and fraction loss in the two cases when nTCP = 99 and link capacity is equal to 100 Mbps. As expected, in both cases the video flow reaches the fair share at 1 Mbps with an RTT small enough to guarantee real-time interaction. However, the GCC flow does not experience any losses in the case of SFQ, whereas Fq CoDel provokes losses due to the CoDel algorithm.		To get a further insight on the different behavior of GCC with SFQ or with Fq Codel in the presence of concurrent TCP traffic, Figure above compares the dynamics of rates, RTT and fraction loss in the two cases when nTCP = 99 and link capacity is equal to 100 Mbps. As expected, in both cases the video flow reaches the fair share at 1 Mbps with an RTT small enough to guarantee real-time interaction. However, the GCC flow does not experience any losses in the case of SFQ, whereas Fq CoDel provokes losses due to the CoDel algorithm.
		+
		+
		+	== Summary ==
		+	Our analysis has shown that, if only real-time video traffic is considered, the end-to-end congestion control is able to contain the queuing delay with zero losses. On the other hand, PIE and CoDel provide the same queuing delay of DropTail but with the drawback of introducing packet losses. When concurrent TCP traffic is considered, both PIE and CoDel are able to effectively reduce the queuing delays compared to DropTail, but they provoke packet losses on the video flow that increase with the number of TCP flows.
		+
		+	Moreover, we show that flow queuing schedulers offer a better solution since they provide flow isolation. The best interplay is obtained with SFQ that obtains the best performance in terms of queuing delay and packet losses.

@@ Riga 101: / Riga 101: @@
 == Real-time Video flow versus multiple TCP flows ==
-[[Immagine:vs_tcp.png|700px|center|''Vs TCP'']]
+[[Immagine:vs_tcp.png|650px|center|''Vs TCP'']]
 <center> '''A single video flow with nTCP concurrent TCP flows over a 10 Mpbs bottleneck link''' </center>
 <br>
@@ Riga 109: / Riga 109: @@
 for any number of concurrent TCP flows; this means that GCC, in order to fairly share the bandwidth with the TCP flow, has been driven in the loss-based mode in which GCC behaves more aggressively in order to fairly share the link with TCP. Video packet losses are higher than 1% when PIE or CoDel are used. In particular, we notice that,  when increasing the number of concurrent TCP flows, induced losses under PIE, CoDel, and Fq CoDel are increased which indeed is detrimental for real-time video quality.
-[[Immagine:vs_tcp_dyn.png|800px|center|''Vs TCP Dyn'']]
+[[Immagine:vs_tcp_dyn.png|850px|center|''Vs TCP Dyn'']]
 <center> '''Video flow and TCP flows rates, RTT, and Video Flow fraction loss dynamics in the case of 99 concurrent TCP flows''' </center>
 <br>
 To get a further insight on the different behavior of GCC with SFQ or with Fq Codel in the presence of concurrent TCP traffic, Figure above compares the dynamics of rates, RTT and fraction loss in the two cases when nTCP = 99 and link capacity is equal to 100 Mbps. As expected, in both cases the video flow reaches the fair share at 1 Mbps with an RTT small enough to guarantee real-time interaction. However, the GCC flow does not experience any losses in the case of SFQ, whereas Fq CoDel provokes losses due to the CoDel algorithm.

←Older revision		Revisione 12:45, 26 Gen 2017
Riga 113:		Riga 113:
	<br>		<br>

−	To get a further insight on the different behavior of GCC with SFQ or with Fq Codel in the presence of concurrent TCP traffic, Figure above compares the dynamics of rates, ~~RTTand~~ fraction loss in the two cases when nTCP = 99 and link capacity is equal to 100 Mbps. As expected, in both cases the video flow reaches the fair share at 1 Mbps with an RTT small enough to guarantee real-time interaction. However, the GCC flow does not experience any losses in the case of SFQ, whereas Fq CoDel provokes losses due to the CoDel algorithm.	+	To get a further insight on the different behavior of GCC with SFQ or with Fq Codel in the presence of concurrent TCP traffic, Figure above compares the dynamics of rates, RTT and fraction loss in the two cases when nTCP = 99 and link capacity is equal to 100 Mbps. As expected, in both cases the video flow reaches the fair share at 1 Mbps with an RTT small enough to guarantee real-time interaction. However, the GCC flow does not experience any losses in the case of SFQ, whereas Fq CoDel provokes losses due to the CoDel algorithm.

@@ Riga 105: / Riga 105: @@
 <br>
-This test case considers one real-time videoflow when competing with a number nTCP of concurrent TCP flows. We consider AQM algorithms, namely PIE
+This test case considers one real-time video flow when competing with a number nTCP of concurrent TCP flows. We consider AQM algorithms, namely PIE
-and CoDel, or packet schedulers, i.e. SFQ and Fq CoDel.
+and CoDel, or packet schedulers, i.e. SFQ and Fq CoDel. In Figure above,  each bar represents the average value and the error bar is the standard deviation; bars are grouped in accordance with the number of concurrent TCP flows. Let us now focus on the loss ratio. Under DT/300, the loss ratio is contained in the range ]0, 0.5]%
 [[Immagine:vs_tcp_dyn.png|550px|center|''Vs TCP Dyn'']]
 <center> '''Video flow and TCP flows rates, RTT, and Video Flow fraction loss dynamics in the case of 99 concurrent TCP flows''' </center>
 <br>

@@ Riga 97: / Riga 97: @@
 This test case compares the video metrics obtained when one video flow runs in isolation over a bottleneck governed by either DT/300, PIE, or CoDel using the settings reported in Table above. We have considered two values for the link capacity b ∈ {1, 2} Mbps and the round trip propagation delay has been set to 50 ms. Regarding the packet loss ratio, average values, and standard deviation are shown. Queuing delays are depicted using a box and whisker plot: the bottom and top of the box are respectively the 25-th and 75-th percentile, whereas the band in the box is the median; the end of the whiskers represent the 5-th and 95-th percentile. The Figure does not depict the channel utilization since it higher than 90% for every experiment.
-Results show that if only real-time video traffic is considered, the end-to-end congestion control is able to contain the queuing delay with zero losses. On the other hand, PIE and CoDel provide the same queuing delay of DropTail but with the drawback of introducing packet losses.
+Results show that if only real-time video traffic is considered, the end-to-end congestion control is able to contain the queuing delay with zero losses. On the other hand, PIE and CoDel provide roughly the same queuing delay of DropTail but with the drawback of introducing packet losses.
 == Real-time Video flow versus multiple TCP flows ==