Re: [Bloat] dash traffic "chunklets" verses pie and fq_codel

[Jonathan Morton <chromatix99@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

While interesting from a scientific point of view, I do think they're
trying to solve the wrong problem here.

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.

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.

- Jonathan Morton

[-- Attachment #2: Type: text/html, Size: 1806 bytes --]