Jonathan Morton <[email protected]> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
