From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8201C3B2AE for ; Thu, 3 Mar 2016 11:05:10 -0500 (EST) Received: from dair-1314.local (c-73-252-201-217.hsd1.ca.comcast.net [73.252.201.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 243B31F495; Thu, 3 Mar 2016 16:05:07 +0000 (UTC) To: aqm@ietf.org, bloat@lists.bufferbloat.net References: <56BB8F05.2030006@mti-systems.com> <56D1F349.6040601@taht.net> <650D8A08-A9FF-4EDF-9374-B4DBF3EB87CD@cisco.com> <81564C0D7D4D2A4B9A86C8C7404A13DA43D85A53@ESESSMB205.ericsson.se> From: =?UTF-8?Q?Dave_T=c3=a4ht?= Message-ID: <56D861AC.4040506@taht.net> Date: Thu, 3 Mar 2016 08:09:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [Bloat] 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: , X-List-Received-Date: Thu, 03 Mar 2016 16:05:10 -0000 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. >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... 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 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. The baseline RTT is tiny compared to the enormous buffers in CMTSes, in particular. > 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 2015 > > Cheers, > -- > Luca De Cicco > Assistant Professor > Politecnico di Bari > > > On Thu, Mar 3, 2016 at 1:13 PM Ingemar Johansson S > > 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 more 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 hand 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 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 > quantify 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äht > > Cc: aqm@ietf.org ; > bloat@lists.bufferbloat.net > > Subject: Re: [aqm] [Bloat] review: Deployment of RITE mechanisms, > in use- > > case trial testbeds report part 1 > > > > > > > On Feb 27, 2016, at 11:04 AM, Dave Täht > 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 the 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 one or > > both to drop a packet - reducing their respective cwnd values. > Depending 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 > retransmit > > 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 > > > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm >