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 2D1DB3B29E for ; Fri, 8 Sep 2017 14:14:49 -0400 (EDT) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (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 807752144A; Fri, 8 Sep 2017 18:14:47 +0000 (UTC) From: Dave Taht To: Jonathan Morton Cc: "Steinar H. Gunderson" , bloat References: <20170908073215.dba5utrwuwvruw55@sesse.net> Date: Fri, 08 Sep 2017 11:14:45 -0700 In-Reply-To: (Jonathan Morton's message of "Fri, 8 Sep 2017 14:50:26 +0300") Message-ID: <87ingtrrai.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Bloat] dash traffic "chunklets" verses pie and fq_codel 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: Fri, 08 Sep 2017 18:14:49 -0000 Jonathan Morton writes: > While interesting from a scientific point of view, I do think they're trying to > solve the wrong problem here. I am always interested in someone repeating an experiment with a few more variables altered. In this case, pacing and BBR would be rather interesting to see. > > As stated in the paper, the big problem with DASH is the tendency of TCPs to > revert to slow start (ie. beginning from a small cwnd) after a gap in > availability of data to transmit. If that occurs after as short an interval as 2 > seconds (the DASH chunk length), I consider that to be a flaw in those TCP > implementations. We also have the decay factors present in the available AQMs. > Theoretically, 2 seconds is as long as DASH should wait while playing video > continuously, in the steady state condition where the link capacity is known and > the buffer is full. I can see little reason for it to wait longer; I would > consider that an implementation flaw in the DASH client. > > Also, given a nearly full buffer, I would expect DASH to resist reducing the > video quality due to a possibly transient reduction in measured link capacity. > If the reduction persists long enough to substantially empty the buffer (say to > 50%), then it would be reasonable to step down in quality to match the new > measurement. Again, this is a quality of implementation problem in the client. > > The other problem their solution addresses, but is not stated as the primary > goal, is to reduce DASH susceptibility to competition versus multiple flow > applications such as Steam downloads. But that is not a problem specific to flow > isolating AQM systems (if anything, it's worse with plain FIFO). They do note > that fq_codel greatly improves the situation versus reverse bulk traffic, just > as it should, but they don't seem to highlight that this benefit is reduced with > "chunklets" in use, according to the measurements presented. My overall joy is generally that "things are better" with fq_codel based queuing solutions than anything else we've yet devised, for yet another form of traffic. Really the only thing left that I worry about (technically) is videoconferencing. It's crossing the chasm to the places where these technologies are most needed - where we have devices with first world fifo over-buffering being deployed into third world bandwidths, and still no headends for any last mile tech (dsl, cable, etc) actually implementing stuff like this. There's a lot of the world left to cover with better Internet. https://trends.google.com/trends/explore?q=bufferbloat > > - Jonathan Morton > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat