[Bloat] [ALU] [aqm] The Impact of Active Queue Management on DASH-based ContentDelivery

[Francini, Andrea (Nokia - US)]

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:aqm-bounces at ietf.org] On Behalf Of Dave Taht
Sent: Tuesday, January 10, 2017 11:08 AM
To: bloat <bloat at lists.bufferbloat.net>; aqm at ietf.org
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
aqm at ietf.org
https://www.ietf.org/mailman/listinfo/aqm