<div dir="ltr">Dear Dave,<div><br></div><div>thanks a bunch for your feedback. My reply is inline.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 3, 2016 at 5:05 PM Dave Täht <<a href="mailto:dave@taht.net">dave@taht.net</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/3/16 4:31 AM, Luca De Cicco wrote:<br>
> Dear Ingemar and all,<br>
><br>
> I hope not to hijack the topic,<br>
<br>
No worries, but I changed the subject line to suit. I strongly support<br>
those writing papers to submit them for discussion to the lists... I<br>
read google scholar regularly but missed these.<br></blockquote><div><br></div><div>Great. Thanks for taking time to browse the papers :)</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>but I would like to add some bits to the<br>
> interesting HAS/DASH<br>
> discussion you bootstrapped.<br>
> Regarding the performance of HAS/DASH adaptive streaming control<br>
> algorithm, the reason for the<br>
> poor performance of rate-based algorithms is due to the ON/OFF behaviour<br>
> of the clients (i.e. video clients<br>
> insert idle periods to control the buffer and concurrent TCP flows can<br>
> take advantage of this).<br>
> This phenomenon was first uncovered in the IMC 2012 paper that Te-Yuan<br>
> et al. named "the downward<br>
> spiral effect" and is also experimentally shown in the following paper<br>
> in the case of several "rate based" algorithms<br>
> (sorry for the advertisement ;)) where we proposed a buffer-based<br>
> adaptive streaming control algorithm:<br>
><br>
> <a href="http://c3lab.poliba.it/images/a/a1/Elastic-pv2013.pdf" rel="noreferrer" target="_blank">http://c3lab.poliba.it/images/a/a1/Elastic-pv2013.pdf</a><br>
> L. De Cicco, V. Caldaralo, V. Palmisano, and S. Mascolo<br>
> ELASTIC: a Client-side Controller for Dynamic Adaptive Streaming over<br>
> HTTP (DASH)<br>
> Proc. of Packet Video Workshop 2013, San Jose, CA, USA, December 2013<br>
<br>
This experiment can be easily repeated with various AQM,AQM/fq<br>
technologies in the link.<br>
<br>
The size of the drop tail queue is not documented...<br>
<br></blockquote><div><br></div><div>IIRC the DT queue size was equal to the BDP. We have also run experiments with tc/netem but we didn't study the impact of AQMs on performance. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is this the netshaper codebase? <a href="http://netshaper.sourceforge.net/" rel="noreferrer" target="_blank">http://netshaper.sourceforge.net/</a> ?<br>
<br>
"NetShaper that performs bandwidth shaping and allows<br>
propagation delays to be set. This tool uses the nfqueue<br>
library provided by Netfilter1<br>
in order to capture and<br>
redirect the packets arriving at the client host to a user space<br>
drop-tail queue, where traffic shaping and measurement are<br>
performed."<br>
<br>
This is in a place where we would just plug the various algorithms into<br>
the sqm-scripts and not do it in userspace.<br>
<br>
The emulated base RTT is not documented. Arguably HAS traffic would<br>
often have a lower base RTT than a random tcp link.<br>
<br></blockquote><div><br></div><div>IIRC the baseRTT was set equal to 50ms.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The dynamic range of the selected rates seems low.<br></blockquote><div><br></div><div>What do you mean by selected rates?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am always harping on the need to test against an upload flow, and to<br>
emulate asymmetric network links common in the home, in general.<br>
<br>
> A more theoretical explanation of rate-based and buffer-based approaches<br>
> can be found here<br>
>  where some properties of hysteresis buffer-based controllers are shown:<br>
><br>
> <a href="http://c3lab.poliba.it/images/b/b1/Acc2015.pdf" rel="noreferrer" target="_blank">http://c3lab.poliba.it/images/b/b1/Acc2015.pdf</a><br>
<br>
Read this also. I guess a key thing I keep wanting to see is the effect<br>
of a web traffic burst - and the reaction time changes with an upload<br>
going on at the same time. </blockquote><div><br></div><div>This can be easily set up. We have released a tool which is able to generate a relatively high number of HAS flows using a single machine (decoding/rendering of the video can be turned off but the dynamics of the control algorithm is not impacted). The tool is also useful to implement/compare different adaptive streaming control algos.</div><div>Please look at:<br></div><div><br></div><div><a href="https://github.com/ldecicco/tapas">https://github.com/ldecicco/tapas</a><br></div><div>and the companion paper:</div><div><a href="http://c3lab.poliba.it/images/f/f3/Tapas-videonext.pdf">http://c3lab.poliba.it/images/f/f3/Tapas-videonext.pdf</a></div><div><br></div><div>(And now I swear I'll stop with the advertisement!)</div><div><br></div><div>Cheers, </div><div>Luca</div></div></div></div>