From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 86F6D3B2D1 for ; Thu, 3 Mar 2016 07:31:27 -0500 (EST) Received: by mail-yw0-x235.google.com with SMTP id b72so13522928ywe.0 for ; Thu, 03 Mar 2016 04:31:27 -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 :cc; bh=ZC/zGN/9bBiD6dIQHsc+6po5O+Uz7xz51f4weSZVVsE=; b=KpZkZXZAEphs77kbUXe3S9LKdKt+Q4FdGzOAGZ0HBP4D7O2r7hzWI6AnXjDm32IpG0 LI387CooKdZu4l63mvFM4sV6Il2jqN0zX/OMDbNMOC41ZC/KE4tLfF++3gaqsaQOIv/+ XGKMBy5cLC5UgJ90bpmGsdldQkTbCeV9Y0GtvCdu916pknuIyY5LVQwIoe3mvVzuXELW nb3a53eGZS3apuI+A96jyyUdQlDjhj1RIYYfaOfdSq3l8kB6HsbWGbHwpRRJV3hWa1EW RMdeLP2W5hUrzfWzzs6Tjcf4xonvf5jVc+Pz0cie7jLt316nodDlIO9Tb20YW8lFMNuh AXVg== 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:cc; bh=ZC/zGN/9bBiD6dIQHsc+6po5O+Uz7xz51f4weSZVVsE=; b=BSJqvcvUsA9M6apRHI5dT4MS7mcXtf6USHTiO79cswcs5QXgrKu4rUYloUuzP5t1qu EyHL+lhoopdej41fRd7BPqba3ypRswRAJBjQIUKA1+pvYB6DAQyn2NucHQ2Daq4WG9h6 Z4b2vjY10EWGg3XorIvx+F9qPoa6zhw8vFFtAaSzU4impuYlqXG0BGBsE+KnlB5LGAFW 0qJiyjMbYe8AUma9D3/pbtcLOHOXRE08ugUzU6310vG+tLLqogbiQt+1f6RBXkI5cjAb si9uiL2KYNeCcfSnm4cO7ySROW6ZnWpEBVbEk2hv59aA7yxOHycMotMYbdA2A8Sr3yzO gFVg== X-Gm-Message-State: AD7BkJKDCRYg2xC/OaDLIuOZ6yFDKqtQWQt7U8qJA8r/NSX/fcOPLAAwfzXSCp3QTo3fdKvoHMEOMGWzhd5Xjw== X-Received: by 10.129.19.214 with SMTP id 205mr1148729ywt.136.1457008287009; Thu, 03 Mar 2016 04:31:27 -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> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA43D85A53@ESESSMB205.ericsson.se> From: Luca De Cicco Message-ID: To: Ingemar Johansson S , "Fred Baker (fred)" , =?UTF-8?Q?Dave_T=C3=A4ht?= Cc: "aqm@ietf.org" , "bloat@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=001a1142996461d1ec052d242d86 X-Mailman-Approved-At: Fri, 08 Apr 2016 15:29:56 -0400 Subject: Re: [Bloat] [aqm] review: Deployment of RITE mechanisms, in use-case trial testbeds report part 1 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 12:31:27 -0000 X-Original-Date: Thu, 03 Mar 2016 12:31:17 +0000 X-List-Received-Date: Thu, 03 Mar 2016 12:31:27 -0000 --001a1142996461d1ec052d242d86 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Ingemar and all, I hope not to hijack the topic, 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 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 Giuseppe Cofano, Luca De Cicco, Saverio Mascolo Characterizing Adaptive Video Streaming Control Systems Proc. of American Control Conference (ACC 2015), Chicago, USA, July 1-3 201= 5 Cheers, -- Luca De Cicco Assistant Professor Politecnico di Bari On Thu, Mar 3, 2016 at 1:13 PM Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > Thanks for the pointer to the RITE paper, will read it carefully. > Some comments on HAS or DASH > The HAS behavior when subject to different AQMs and other competing > background traffic, depends heavily the rate control algorithm. > Investigations we have done and also e.g. the Netflix papers and lately > also the BOLA paper (link below) shows that rate based algorithms are mor= e > easily starved out by competing traffic than the buffer level based > algorithms. The bufferbased algorithms (Netflix, BOLA) are more > opportunistic and TCP is more allowed to work like large file downloads > when the links are fully utilized. Rate based algorithms on the other han= d > can more easily end up in a vicious circle, a low download rate is > detected, so the next segment requested is with a reduced rate, other > traffic will grab a larger share, and this repeats itself until the lowes= t > rate is reached. > This is elaborated upon in the paper "A Buffer-Based Approach to Rate > Adaptation: Evidence from a Large Video Streaming Service" by Te-Yuan Hua= ng > et.al. > I don't have full insight how MS Silverlight operates so I cannot quantif= y > it is rate based or buffer based. > > BOLA : http://arxiv.org/pdf/1601.06748.pdf > > /Ingemar > > > -----Original Message----- > > From: Fred Baker (fred) [mailto:fred@cisco.com] > > Sent: den 2 mars 2016 19:09 > > To: Dave T=C3=A4ht > > Cc: aqm@ietf.org; bloat@lists.bufferbloat.net > > Subject: Re: [aqm] [Bloat] review: Deployment of RITE mechanisms, in us= e- > > case trial testbeds report part 1 > > > > > > > On Feb 27, 2016, at 11:04 AM, Dave T=C3=A4ht wrote: > > > > > > https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs244- > > 14-confused-timid-and-unstable-picking-a-video-streaming-rate-is-hard/ > > > > > >> o the results are very poor with a particular popular AQM > > > > > > Define "very poor". ? > > > > Presuming this is Adaptive Bitrate Video, as in Video-in-TCP, we (as in > Cisco > > engineers, not me personally; you have met them) have observed this as > > well. Our belief is that this is at least in part a self-inflicted > wound; when the > > codec starts transmission on any four second segment except the first, > there > > is no slow-start phase because the TCP session is still open (and in th= e > case of > > some services, there are several TCP sessions open and the application > > chooses the one with the highest cwnd value). You can now think of the > > behavior of the line as repeating a four phase sequence: nobody is > talking, > > then one is talking, then both are, and then the other is talking. When > only > > one is talking, whichever it is, its cwnd value is slowing increasing - > especially > > if cwnd*mss/rtt < bottleneck line rate, minimizing RTT. At the start of > the > > "both are talking" phase, the one already talking has generally found a > cwnd > > value that fills the line and its RTT is slowly increasing. The one > starting sends > > a burst of cwnd packets, creating an instant queue and often causing on= e > or > > both to drop a packet - reducing their respective cwnd values. Dependin= g > on > > the TCP implementation in question at the sender, if the induced drop > isn't a > > single packet but is two or three, that can make the affected session > pause > > for as many RTO timeouts (Reno), RTTs (New Reno), or at least retransmi= t > > the lost packets in the subsequent RTT and then reduce cwnd by at least > that > > amount (cubic) and maybe half (SACK). > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --001a1142996461d1ec052d242d86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Ingemar and all,=C2=A0

I hope not = to hijack the topic, but I would like to add some bits to the interesting H= AS/DASH=C2=A0
discussion you bootstrapped.
Regarding th= e performance of HAS/DASH adaptive streaming control algorithm, the reason = for the=C2=A0
poor performance of rate-based algorithms is due to= the ON/OFF behaviour of the clients (i.e. video clients
insert i= dle periods to control the buffer and concurrent TCP flows can take advanta= ge of this).=C2=A0
This phenomenon was first uncovered in the IMC= 2012 paper that Te-Yuan et al. named "the downward=C2=A0
sp= iral effect"=C2=A0and is also experime= ntally shown in the following paper in the case of several "rate based= " algorithms
(sorry for the advertisement ;))=C2=A0where we proposed a buffer-based adaptive str= eaming control algorithm:

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 W= orkshop 2013, San Jose, CA, USA, December 2013

A more theoretical ex= planation of rate-based and buffer-based approaches can be found here
= =C2=A0where some properties of hysteresis buffer-based controllers are show= n:

Giuseppe Cofano, Luca De Cicco, Saverio M= ascolo
Characterizing Adaptive Video Streaming Control= Systems
Proc. of American Control Conference (ACC 2015), Chicago, USA, = July 1-3 2015

Cheers,
--
Luca De= Cicco
Assistant Professor
Politecnico di Bari


On = Thu, Mar 3, 2016 at 1:13 PM Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote= :
Hi

Thanks for the pointer to the RITE paper, will read it carefully.
Some comments on HAS or DASH
The HAS behavior when subject to different AQMs and other competing backgro= und traffic, depends heavily the rate control algorithm.
Investigations we have done and also e.g. the Netflix papers and lately als= o the BOLA paper (link below) shows that rate based algorithms are more eas= ily starved out by competing traffic than the buffer level based algorithms= . The bufferbased algorithms (Netflix, BOLA) are more opportunistic and TCP= is more allowed to work like large file downloads when the links are fully= utilized. Rate based algorithms on the other hand can more easily end up i= n a vicious circle, a low download rate is detected, so the next segment re= quested is with a reduced rate, other traffic will grab a larger share, and= this repeats itself until the lowest rate is reached.
This is elaborated upon in the paper "A Buffer-Based Approach to Rate = Adaptation: Evidence from a Large Video Streaming Service" by Te-Yuan = Huang et.al.
I don't have full insight how MS Silverlight operates so I cannot quant= ify it is rate based or buffer based.

BOLA : http://arxiv.org/pdf/1601.06748.pdf

/Ingemar

> -----Original Message-----
> From: Fred Baker (fred) [mailto:fred@cisco.com]
> Sent: den 2 mars 2016 19:09
> To: Dave T=C3=A4ht
> Cc: aqm@ietf.org= ; bloat@li= sts.bufferbloat.net
> Subject: Re: [aqm] [Bloat] review: Deployment of RITE mechanisms, in u= se-
> case trial testbeds report part 1
>
>
> > On Feb 27, 2016, at 11:04 AM, Dave T=C3=A4ht <dave@taht.net> wrote:
> >
> > https://reproducingnetwo= rkresearch.wordpress.com/2014/06/03/cs244-
> 14-confused-timid-and-unstable-picking-a-video-streaming-rate-is-hard/=
> >
> >>=C2=A0 =C2=A0o the results are very poor with a particular pop= ular AQM
> >
> > Define "very poor". ?
>
> Presuming this is Adaptive Bitrate Video, as in Video-in-TCP, we (as i= n Cisco
> engineers, not me personally; you have met them) have observed this as=
> well. Our belief is that this is at least in part a self-inflicted wou= nd; when the
> codec starts transmission on any four second segment except the first,= there
> is no slow-start phase because the TCP session is still open (and in t= he case of
> some services, there are several TCP sessions open and the application=
> chooses the one with the highest cwnd value). You can now think of the=
> behavior of the line as repeating a four phase sequence: nobody is tal= king,
> then one is talking, then both are, and then the other is talking. Whe= n only
> one is talking, whichever it is, its cwnd value is slowing increasing = - especially
> if cwnd*mss/rtt < bottleneck line rate, minimizing RTT. At the star= t of the
> "both are talking" phase, the one already talking has genera= lly found a cwnd
> value that fills the line and its RTT is slowly increasing. The one st= arting sends
> a burst of cwnd packets, creating an instant queue and often causing o= ne or
> both to drop a packet - reducing their respective cwnd values. Dependi= ng on
> the TCP implementation in question at the sender, if the induced drop = isn't a
> single packet but is two or three, that can make the affected session = pause
> for as many RTO timeouts (Reno), RTTs (New Reno), or at least retransm= it
> the lost packets in the subsequent RTT and then reduce cwnd by at leas= t that
> amount (cubic) and maybe half (SACK).
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
--001a1142996461d1ec052d242d86--