Re: [aqm] Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC

Jonathan Morton <chromatix99@gmail.com> Fri, 25 March 2016 20:20 UTC

Return-Path: <chromatix99@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9636112D70A; Fri, 25 Mar 2016 13:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dn7VPhvB3ANX; Fri, 25 Mar 2016 13:20:29 -0700 (PDT)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A2C12D74B; Fri, 25 Mar 2016 13:20:28 -0700 (PDT)
Received: by mail-lf0-x22f.google.com with SMTP id q73so58227667lfe.2; Fri, 25 Mar 2016 13:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nPS19JZVRFmmXUAVT8MmyJ0ZRTYNuu6SutjEArUym2Y=; b=PlVd4j1/W835Oki/c56UT763J+QYxRCMQH7QlqXEBDoeB/ly7K2jXRp/t6R8gayjsn 6do7KAYPzix3A77K+jn2d9ajM9zOOEXfyIzL3xUkS+JFRno+jknDco/PVauz5GH8raz6 mPmb/O4Q+jJQOq8CT3fqDnSaW8rAHNk5quFyjx8z7S01TbfZ48m1+82x2MuIqsBoDXXk YSj3lfUunwErlYgcys55ZlEyMmuENC9t5LXVRw0Jf+bfj6y9AuEkOMQnWx5PJSpocqJ6 xiyxj+UL9rlM+CyzF+GB0RLyBDtVbcbufX4pBUr+Qrm5kJjkAMXIwl0GYtxzRGRR+i0B BimQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nPS19JZVRFmmXUAVT8MmyJ0ZRTYNuu6SutjEArUym2Y=; b=FUjdUHdYpNSIyQLNguLBo4RuBIgWx9mlKb5ghM+AVQPCngZtmUWSt1U2fhGxvKAIha qCaKo+5KGmWOXoDcpnzAic+LcG7wNZJwOxhDoSOZKkWrumarDJQF87/gJ5XLBoBPYNor JxmAiASaNVZzs6nSoZZs/yXK1nSAMrfv6sCRoBFC4EDpF/ib0HQfgDXS5UBDY7ZYHHm1 LF9o45JtMvritjFgUsdpA80e25nQtMllmawF5uZvKZNq5ziF8KvY2DHhCDNs298xs27f AqilzIE4hMRVMR1OSpO2JOVzbSMd6rC/0uW2pJ2yjKIPE95wUBJcJnkq13W+Gj8wSUbh XFeQ==
X-Gm-Message-State: AD7BkJK+NcHd01zLN1tJkmRE0N7EOTMutHbDTKRrqen+eOVJc6yeO2SgBa913TqBMF084w==
X-Received: by 10.25.35.88 with SMTP id j85mr6116358lfj.148.1458937226324; Fri, 25 Mar 2016 13:20:26 -0700 (PDT)
Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id e6sm2201380lbk.32.2016.03.25.13.20.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2016 13:20:25 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: [aqm] Last Call: <draft-ietf-aqm-fq-codel-05.txt> (FlowQueue-Codel) to Experimental RFC
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <56F58BD8.20708@bobbriscoe.net>
Date: Fri, 25 Mar 2016 22:20:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AA012A7-2E29-47D1-B522-B28E5A6EDB18@gmail.com>
References: <20160303172022.12971.79276.idtracker@ietfa.amsl.com> <56EBDA04.3020500@bobbriscoe.net> <8737rox89h.fsf@alrua-desktop.borgediget.toke.dk> <56F037AE.90608@bobbriscoe.net> <6610EDF8-D738-479E-B53C-2315A54EFA68@gmail.com> <56F58BD8.20708@bobbriscoe.net>
To: Bob Briscoe <research@bobbriscoe.net>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/MbtUrG14qRAX7AZ13SiOfAPTfWU>
X-Mailman-Approved-At: Mon, 28 Mar 2016 08:12:31 -0700
Cc: draft-ietf-aqm-fq-codel@ietf.org, =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= <toke@toke.dk>, ietf@ietf.org, aqm-chairs@ietf.org, mls.ietf@gmail.com, aqm@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Mar 2016 20:20:31 -0000

>> You state that the new codecs “would have delivered twice as many videos with the same quality over the same capacity”, and video “was the dominant traffic”, *and* the network was the bottleneck while running the new codecs.
>> 
>> The logical conclusion must be either that the network was severely under-capacity

> Nope. The SVLAN buffer (Service VLAN shared by all users on the same DSLAM) at the Broadband Network Gateway (BNG) became the bottleneck during peak hour, while at other times each user's CVLAN (Customer VLAN) at the BNG was the bottleneck.

In other words, yes the network *was* congested…

> The proposition was to halve the SVLAN capacity serving the same CVLANs by exploiting the multiplexing gain of equitable quality video... explained below.

…and this is one of the key facts that helps me understand the use-case.

I’d be a lot more sympathetic if, as your original description strongly implied, it was all about getting better quality or more capacity from a given network, rather than attempting to *halve the capacity* of a part of the network that was *already congested* at peak hour.  The latter strategy is wrong-headed, especially from the “customer experience” point of view you espouse.

> A typical (not contrived) example bit-rate trace of constant quality video is on slide 20 of a talk I gave for the ICCRG in May 2009, when I first found out about this research: http://www.bobbriscoe.net/presents/0905iccrg-pfldnet/0905iccrg_briscoe.pdf

I understand CQR versus VBR versus CBR.  Now I also understand that “equitable quality” means that the codec adapts the quality to the available bandwidth - which is not the same as CQR, and is more akin to VBR.  This is the other key fact that was omitted from your previous description.

It’s also implicitly clear that the video sources are under the ISP’s control, hence relatively centralised, otherwise they wouldn’t be able to dictate which codec was used.  In theory they could therefore share information explicitly about network conditions each individual stream experiences.

Instead, it seems information was shared only implicitly, by relying on the specific behaviour of a single queue at each bottleneck, which is to give the same congestion signal (whether that be loss, delay, or ECN) to all flows through it.  WFQ broke that assumption, as would any other flow-isolation scheme which avoided impeding lightweight flows when controlling bulk flows, regardless of the precise definition of a “flow".

But I do have to ask: what is the *qualitative* difference between the action of WFQ to equalise capacity per flow, and the off-peak scenario where each flow is bottlenecked at the CVLANs?  I don’t see it.

 - Jonathan Morton