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