Discussion:
dash traffic "chunklets" verses pie and fq_codel
(too old to reply)
Dave Taht
2017-09-07 23:52:54 UTC
Permalink
Raw Message
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
Steinar H. Gunderson
2017-09-08 07:32:15 UTC
Permalink
Raw Message
Post by Dave Taht
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/
Jonathan Morton
2017-09-08 11:50:26 UTC
Permalink
Raw Message
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
Dave Taht
2017-09-08 18:14:45 UTC
Permalink
Raw Message
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
https://lists.bufferbloat.net/listinfo/bloat
Dave Taht
2017-09-08 17:51:37 UTC
Permalink
Raw Message
On Fri, Sep 8, 2017 at 12:32 AM, Steinar H. Gunderson
Post by Steinar H. Gunderson
Post by Dave Taht
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.
Post by Steinar H. Gunderson
/* Steinar */
--
Homepage: https://www.sesse.net/
_______________________________________________
Bloat mailing list
https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
Loading...