From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9927C3B2D0 for ; Thu, 3 Mar 2016 13:49:53 -0500 (EST) Received: by mail-yw0-x234.google.com with SMTP id g127so25472149ywf.2 for ; Thu, 03 Mar 2016 10:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Oe5G85VwMqMPnI8gL5KNsXQIF+nVECZnKoXnu127dRU=; b=o6+J1S/YYVeItC8Izpqzndjae67evvawZmBVylCrHU9hX4V66B800erMmEoQkOhLJe Iktf491vt4NILK3yUYbw3db29p845r/GI3iBJ8mo7JA+x6NtjZS5OJncrUNPgMhF1vFD zsudaLhwSP5UfCKWbtwhKDAo85QmX/eAhFWPbIrlEWyK97Ip628kwVNyvZi5aJk3AXM0 yecp8sECeaRh7WjwhSsiltqeGKjI4krWTnpZooBOBKvkcbYMTB4nWm7U9+P7IEDUfkGN GPUvfVdgU7lHThubXa9Xh+9Nz640vUn/R8E5Jk7cD+AexZ+k4i/jQzUVpQR8MpzAiGo4 +3eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Oe5G85VwMqMPnI8gL5KNsXQIF+nVECZnKoXnu127dRU=; b=VmNPaJaf2flDVrY+A4txkdZCvjK8nbzPFiMCMlECq927VnLl157nA11qgjOkQmPmyw KuHv//WC4OrV4hkss5iT0BuWzYiT7LUqfuvTWf4QPr+V8yDnzrzsdwY5afIcKHtf6ZrQ lTJsbhlh7bzjLKXxfg8kNtqjINZ9EIRKA3q61Q6c189IZdbsYJAejVy0KLEVWs2iSkmD sV7J/nDB3WsJt+3TOSFKvD+ERgJrZWbSjQND9oHjeJdPoV78W7muOXHTG4Pb3wVP/fhi VhJ42YO2Xa2DBJHevCGt71Xa9zegAuA13yd/hznd5gRPjVVZW18SRcSvPMzSjnP/A2Nw ynPg== X-Gm-Message-State: AD7BkJK4lj6Ew7Cw2cq2R8P8ztv0EvH4tGaPwyooRWbwlh0bG+GCm+esnFsEMDaGtv8LdPtbXfHlr2SQO1MYYQ== X-Received: by 10.129.33.67 with SMTP id h64mr2335618ywh.83.1457030992853; Thu, 03 Mar 2016 10:49:52 -0800 (PST) MIME-Version: 1.0 References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> <650D8A08-A9FF-4EDF-9374-B4DBF3EB87CD@cisco.com> <81564C0D7D4D2A4B9A86C8C7404A13DA43D85A53@ESESSMB205.ericsson.se> <56D861AC.4040506@taht.net> In-Reply-To: <56D861AC.4040506@taht.net> From: Luca De Cicco Message-ID: To: =?UTF-8?Q?Dave_T=C3=A4ht?= , aqm@ietf.org, bloat@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=001a11425f16c183cd052d2976dc X-Mailman-Approved-At: Fri, 08 Apr 2016 15:29:56 -0400 Subject: Re: [Bloat] [aqm] HAS traffic behaviors X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 03 Mar 2016 18:49:53 -0000 X-Original-Date: Thu, 03 Mar 2016 18:49:42 +0000 X-List-Received-Date: Thu, 03 Mar 2016 18:49:53 -0000 --001a11425f16c183cd052d2976dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Dave, thanks a bunch for your feedback. My reply is inline. On Thu, Mar 3, 2016 at 5:05 PM Dave T=C3=A4ht 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 behaviou= r > > 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 approache= s > > 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 --001a11425f16c183cd052d2976dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dave,

thanks a bunch for your feed= back. My reply is inline.

On Thu, Mar 3, 2016 at 5:05 PM Dave T=C3=A4ht <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 :)
= =C2=A0=C2=A0
>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 behavio= ur
> 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/Elasti= c-pv2013.pdf
> L. De Cicco, V. Caldaralo, V. Palmisano, and S. Mascolo
> ELASTIC: a Client-side Controller for Dynamic Adaptive Streaming over<= br> > HTTP (DASH)
> Proc. of Packet Video Workshop 2013, San Jose, CA, USA, December 2013<= br>
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 th= e BDP. We have also run experiments with tc/netem but we didn't study t= he impact of AQMs on performance.=C2=A0
=C2=A0
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.


The dynamic range of the selected rates seems low.
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 approach= es
> can be found here
>=C2=A0 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 eas= ily 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 im= pacted). The tool is also useful to implement/compare different adaptive st= reaming control algos.
Please look at:

https://github.com/ldecicc= o/tapas
and the companion paper:

(And now I sw= ear I'll stop with the advertisement!)

Cheers,= =C2=A0
Luca
--001a11425f16c183cd052d2976dc--