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

Jonathan Morton <> Thu, 24 March 2016 20:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C24BA12D7AA; Thu, 24 Mar 2016 13:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W4hIi3RLmNfM; Thu, 24 Mar 2016 13:09:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F348F12D842; Thu, 24 Mar 2016 13:09:07 -0700 (PDT)
Received: by with SMTP id c62so40004441lfc.1; Thu, 24 Mar 2016 13:09:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vhCHbISuKTTQFuQo7cn84XKK9XIlAEkHAQcbXwXBtyk=; b=UQ4vmHdDXcnYs9MOVbK10mAtoBxBFa9kUlJeEZDleaI7XznEL1BnRYxCS5TRi3wkY8 iLGICm028AK686VQ7XZNiF9JsB00TSjJaNgKsv7zUUToZ6BQoHyVEEYjbwSnWK4nzbG+ GybgqZxCiM7xx5oDmsSn5FQk6viPSrSmjAsg91DRu/QknDRD7sGrvx95JF9aSenbokYc dFF4b5Dmv4M9AmlqrS12TwLpG5Glf5OPzhtTquFZhwnYO9URwkONZpqYjynhjynM9eq+ sXlQ/x3JMcZRFLVLktK3I1tx9uYn7AOc3qCWxqbyiQMa8Wj2jMvWvUYKZ2NMLONQUatf Kr3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vhCHbISuKTTQFuQo7cn84XKK9XIlAEkHAQcbXwXBtyk=; b=XGA/u+h5ovO2/D53k0UtEuJhUXb/oNcBOg6K/C2fDxlZqX8CWLC1A9Eimc2zNQuLyJ JGS6zihX/5/qYvBboAQnGuQAikDivXCYnpccYEzguXHJaN/Wg9ps19jWk9RrVuW/bVzK 0OWsn3iPR7c+/SyeycNKe3CmkSKjyQHl/cOi6N9auGjv0oHOWlEXI6Z1kDpoPSsiOkbg Q9LeL6NY4bO29gK1MgYSAR+i16JqqiPJjPqjyQ1dUBiDuY5vaxTWVhdqJT0WcEEWHI6v KykBF776UTnRUtvLizGiJBciv1Qn44rrakuSFPU76EwgVaeJEVekAYQl+L8jF7fkB86L T6yg==
X-Gm-Message-State: AD7BkJK8N1BF1+QcOQnC2PCSDs8XnLT+4BQV9udiwd1/3tdQEBpmfa1Syh6PPvUs3kTZww==
X-Received: by with SMTP id o134mr4442927lfe.35.1458850146200; Thu, 24 Mar 2016 13:09:06 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g202sm1418883lfg.42.2016. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2016 13:09:05 -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 <>
In-Reply-To: <>
Date: Thu, 24 Mar 2016 22:08:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
X-Mailman-Approved-At: Fri, 25 Mar 2016 09:30:41 -0700
Cc:, Toke Høiland-Jørgensen <>,,,,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Mar 2016 20:09:10 -0000

> On 21 Mar, 2016, at 20:04, Bob Briscoe <> wrote:
> The experience that led me to understand this problem was when a bunch of colleagues tried to set up a start-up (a few years ago now) to sell a range of "equitable quality" video codecs (ie constant quality variable bit-rate instead of constant bit-rate variable quality). Then, the first ISP they tried to sell to had WFQ in its Broadband remote access servers. Even tho this was between users, not flows, when video was the dominant traffic, this overrode the benefits of their cool codecs (which would have delivered twice as many videos with the same quality over the same capacity.

This result makes no sense.

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 and was *also* the bottleneck, only twice as hard, under the old codecs; or that there was insufficient buffering at the video clients to cope with temporary shortfalls in link bandwidth; or that demand for videos doubled due to the new codecs providing a step-change in the user experience (which feeds back into the network capacity conclusion).

In short, it was not WFQ that caused the problem.

 - Jonathan Morton