It looks like tcp_slow_start_after_idle was not disabled in the experiments. If this is indeed the case, it would be interesting to see what happens when the option is disabled at the server, so that the transmission of a new chunk can start at a generally faster rate. 4K video makes this option even more relevant, especially when RTT is large.
With tcp_slow_start_after_idle disabled, the fq_nocodel scheme of Toke's study (http://dx.doi.org/10.1016/j.comnet.2015.07.014) would also be good to evaluate, especially with a total buffer size much larger than BDP: DASH does not suffer from self-inflicted delay as much as it does from packet losses, and empties its dedicated queue in between video chunks. Andrea -----Original Message----- From: aqm [mailto:[email protected]] On Behalf Of Dave Taht Sent: Tuesday, January 10, 2017 11:08 AM To: bloat <[email protected]>; [email protected] Subject: [ALU] [aqm] The Impact of Active Queue Management on DASH-based ContentDelivery This was quite good. I particularly liked the invention of the "instability index". Jonathan Kua, Grenville Armitage and Philip Branch, "The Impact of Active Queue Management on DASH-based Content Delivery," in 41st Annual IEEE Conference on Local Computer Networks (LCN), Dubai, UAE, 7 - 10 November 2016, https://doi.org/10.1109/LCN.2016.24 (more easily available via: http://sci-hub.bz/10.1109/LCN.2016.24# ) I hope a test like this gets repeated against BBR (and for that matter, cake), and against a larger dynamic range of bandwidths (4k video, anyone)? _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
