<p dir="ltr">While interesting from a scientific point of view, I do think they're trying to solve the wrong problem here.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>