Re: [aqm] [ALU] The Impact of Active Queue Management on DASH-based ContentDelivery
"Francini, Andrea (Nokia - US)" <andrea.francini@nokia-bell-labs.com> Tue, 10 January 2017 17:37 UTC
Return-Path: <andrea.francini@nokia-bell-labs.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9BF129D3B for <aqm@ietfa.amsl.com>; Tue, 10 Jan 2017 09:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_xdVrhv1cZE for <aqm@ietfa.amsl.com>; Tue, 10 Jan 2017 09:37:36 -0800 (PST)
Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37B9F128B44 for <aqm@ietf.org>; Tue, 10 Jan 2017 09:37:36 -0800 (PST)
Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 4EAD853317B92; Tue, 10 Jan 2017 17:37:33 +0000 (GMT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id v0AHbYGM031284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Jan 2017 17:37:35 GMT
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id v0AHbGpJ012387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Jan 2017 17:37:31 GMT
Received: from US70TWXCHMBA12.zam.alcatel-lucent.com ([169.254.6.35]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Tue, 10 Jan 2017 12:37:22 -0500
From: "Francini, Andrea (Nokia - US)" <andrea.francini@nokia-bell-labs.com>
To: Dave Taht <dave.taht@gmail.com>, bloat <bloat@lists.bufferbloat.net>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: [ALU] [aqm] The Impact of Active Queue Management on DASH-based ContentDelivery
Thread-Index: AQHSa1vMN6I8gSSxc0i/CMm7R5tPf6Ex9S2g
Date: Tue, 10 Jan 2017 17:37:22 +0000
Message-ID: <1BFAC0A1D7955144A2444E902CB628F8D641D35C@US70TWXCHMBA12.zam.alcatel-lucent.com>
References: <CAA93jw7kWJhmr-Su+BptKYo7P7DUmo5vsLDswBcpZSia+KvyjA@mail.gmail.com>
In-Reply-To: <CAA93jw7kWJhmr-Su+BptKYo7P7DUmo5vsLDswBcpZSia+KvyjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/aqm/2zXHht8ixCerW-sIv3YBSQ_gIIE>
Subject: Re: [aqm] [ALU] The Impact of Active Queue Management on DASH-based ContentDelivery
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2017 17:39:32 -0000
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@ietf.org] On Behalf Of Dave Taht Sent: Tuesday, January 10, 2017 11:08 AM To: bloat <bloat@lists.bufferbloat.net>; aqm@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@ietf.org https://www.ietf.org/mailman/listinfo/aqm
- [aqm] The Impact of Active Queue Management on DA… Dave Taht
- Re: [aqm] [ALU] The Impact of Active Queue Manage… Francini, Andrea (Nokia - US)