Re: [Bloat] [aqm] HAS traffic behaviors

[Luca De Cicco <ldecicco@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3822 bytes --]

Dear Dave,

thanks a bunch for your feedback. My reply is inline.

On Thu, Mar 3, 2016 at 5:05 PM Dave Täht <dave@taht.net> 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

[-- Attachment #2: Type: text/html, Size: 5436 bytes --]