From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mcr@sandelman.ca>
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id ED6FC21FED3;
	Fri, 31 Jul 2015 13:31:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21])
	by tuna.sandelman.ca (Postfix) with ESMTP id E92B420620;
	Fri, 31 Jul 2015 16:40:44 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179)
	id 663DB63AEC; Fri, 31 Jul 2015 16:23:27 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1])
	by sandelman.ca (Postfix) with ESMTP id 4EF9763751;
	Fri, 31 Jul 2015 16:23:27 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <CAJq5cE1CmHjhkmG-_c3yLEX-uViTMk7OVf9trS+gEB6Djpw4gQ@mail.gmail.com>
References: <E9C29602-7F1D-43AD-980C-050B58FA0AC6@iii.ca>
	<CAA93jw63gm1h9R4x_LZ2Po-Xqk8H1kYYmBtU_pb1kzVHOzAQbQ@mail.gmail.com>
	<356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com>
	<5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de>
	<CAJq5cE0ShGs43O=BBNH5WWHPxaJq2TJsFGs06VTpgdUmB4x06w@mail.gmail.com>
	<4D24A497-5784-493D-B409-F704804326A7@gmx.de>
	<1438361254.45977158@apps.rackspace.com>
	<CAJq5cE1CmHjhkmG-_c3yLEX-uViTMk7OVf9trS+gEB6Djpw4gQ@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;
	<'$9xN5Ub#
	z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
Date: Fri, 31 Jul 2015 16:23:27 -0400
Message-ID: <14098.1438374207@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: make-wifi-fast@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] [Make-wifi-fast] [tsvwg] Comments on
	draft-szigeti-tsvwg-ieee-802-11e
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Development issues regarding the cerowrt test router project
	<cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2015 20:32:23 -0000


Jonathan Morton <chromatix99@gmail.com> wrote:
    >> I think that is achievable, *even if there is a WiFi network in the
    > middle*, by thinking about the fact that the shared airwaves in a WiFi
    > network behaves like a single link, so all the queues on individual
    > stations are really *one queue*, and that the optimal behavior of that
    > link will be achieved if there is at most one packet queued at a time.

    > I agree that queues should be kept short in general. However I don't
    > think single packet queues are achievable in the general case.

    > The general case includes Wi-Fi networks, whose TXOP overhead is so
    > ruinously heavy that sending single MTU sized packets is
    > inefficient. Aggregating multiple packets into one TXOP requires those
    > several packets to be present in the buffer at that moment.

Agreed... if one has a minimum of two queues (and *fq-codel has at least that
many), why isn't the naive method of:
       1) send everything from the low-latency queue
       2) send the other stuff until the TXOP is full

enough?  codel will keep the queues short.
The key thing I think, is that the markings (1)/(2) above be passed along
through all "subqueues"...