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

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

[Dave Taht]

good read:

http://caia.swin.edu.au/cv/jkua/preprint/jkua-icccn2017-chunklets-preprint-10may17.pdf

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

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

[Steinar H. Gunderson]

On Thu, Sep 07, 2017 at 04:52:54PM -0700, Dave Taht wrote:
> good read:
> 
> http://caia.swin.edu.au/cv/jkua/preprint/jkua-icccn2017-chunklets-preprint-10may17.pdf

Aaaaa!

“For example, FQ-CoDel isolates individual traffic flows into
sub-queues then serves each sub-queue with a Deficit Round
Robin (DRR) scheduler. The result is relatively even capacity
sharing, which may actually be detrimental to a DASH flow
(often a single, persistent TCP connection) that is competing
with multiple other concurrent TCP flows.”

Isn't this just an AQM sabotage scheme?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

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

[Jonathan Morton]

[-- 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 --]

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

[Dave Taht]

On Fri, Sep 8, 2017 at 12:32 AM, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Thu, Sep 07, 2017 at 04:52:54PM -0700, Dave Taht wrote:
>> good read:
>>
>> http://caia.swin.edu.au/cv/jkua/preprint/jkua-icccn2017-chunklets-preprint-10may17.pdf
>
> Aaaaa!
>
> “For example, FQ-CoDel isolates individual traffic flows into
> sub-queues then serves each sub-queue with a Deficit Round
> Robin (DRR) scheduler. The result is relatively even capacity
> sharing, which may actually be detrimental to a DASH flow
> (often a single, persistent TCP connection) that is competing
> with multiple other concurrent TCP flows.”
>
> Isn't this just an AQM sabotage scheme?

Well, first, a paper showing vastly better behavior for dash traffic
for fq_codel over pie and tail drop was a reason to celebrate.

Secondly, dash is kind of special in that you *are* constantly probing
for more bandwidth for a replacement stream, and that does interact
with fq in some difficult ways.

I wouldn't go as far as calling using two flows to do a probe like
this "sabotage", but a practical means of finding the right queue and
getting a bit more bandwidth overall. The multipath mosh work (sadly
still not mainlined when last I looked) was resistant to hash
collisions.

It is unclear from the paper to what extent the aqm kicks in - I would
have liked some packet drop figures and their onset.

I keep hoping to see some resumption of bittorrent experiments...

Lastly, I liked the idea of a (in)stability index.

> /* Steinar */
> --
> Homepage: https://www.sesse.net/
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

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

[Dave Taht]

Jonathan Morton <chromatix99@gmail.com> 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