From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3A52F21FED6; Fri, 31 Jul 2015 13:45:08 -0700 (PDT) Received: by ykdv124 with SMTP id v124so28007125ykd.0; Fri, 31 Jul 2015 13:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lO+CXzqZasfjw+H0gekGDHlmol9FWSGdFegbwNgzC+8=; b=HDvatFDrh22hM27sqne1pzBKUNcYXY5hQC4sO/ckIVtFNpJ88SGid7bZVYbv+SN6iq JItEgs8K7gmKyny8YrHyVPJwUYPgKjoGHv67fmbibBualFIOiT1UJfvWJJLdElWjL9c8 AB7D6aLuukcZpkZCka872XXlq7H/umNW7RePJCGl426hwSt5D8TsJwi0A7euhoUWZa+M 5+aUsLUIuVot/qR9yO3GlgtKbHMMOO22dnDKp0aJ3w2/7gwhD6Nifw6HKGvrK8GxwhqS zWG7g2MWpibAfAP7V0Ogp7jyhCGROEfd5sqZKdqStleAAznKqUBEu2gxHdLZRxi3QJwV +qfA== MIME-Version: 1.0 X-Received: by 10.170.176.87 with SMTP id s84mr5930973ykd.46.1438375507811; Fri, 31 Jul 2015 13:45:07 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Fri, 31 Jul 2015 13:45:07 -0700 (PDT) Received: by 10.37.26.9 with HTTP; Fri, 31 Jul 2015 13:45:07 -0700 (PDT) In-Reply-To: <14098.1438374207@sandelman.ca> References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> <4D24A497-5784-493D-B409-F704804326A7@gmx.de> <1438361254.45977158@apps.rackspace.com> <14098.1438374207@sandelman.ca> Date: Fri, 31 Jul 2015 23:45:07 +0300 Message-ID: From: Jonathan Morton To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11393376326375051c31e543 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 20:45:37 -0000 --001a11393376326375051c31e543 Content-Type: text/plain; charset=UTF-8 There is some subtlety of terminology here... Fq_codel has many queues, but they are not a priori assigned as "low latency" or otherwise. There is a dynamic sense of whether each queue is handling sparse or bulk traffic, with the sparse queues being serviced first. This is a type of priority queuing which is difficult to game (and completely ignores Diffserv). Cake does the same thing, and additionally divides the queue using Diffserv. Etcetera. Both fq_codel and cake deliver one packet at a time. This is a feature of the qdisc API within the kernel. They have no visibility of what aggregation might be happening at the hardware level, only that the driver is requesting a packet. Wi-Fi hardware implementing 802.11e tends to have four queues, each of which is a dumb FIFO, and services only one of them per TXOP (probably the highest priority one). It doesn't even do the "naive" thing you mention - which goes some way to illustrate the point of view of the typical hardware engineer. - Jonathan Morton --001a11393376326375051c31e543 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

There is some subtlety of terminology here...

Fq_codel has many queues, but they are not a priori assigned= as "low latency" or otherwise. There is a dynamic sense of wheth= er each queue is handling sparse or bulk traffic, with the sparse queues be= ing serviced first. This is a type of priority queuing which is difficult t= o game (and completely ignores Diffserv).

Cake does the same thing, and additionally divides the queue= using Diffserv. Etcetera.

Both fq_codel and cake deliver one packet at a time. This is= a feature of the qdisc API within the kernel. They have no visibility of w= hat aggregation might be happening at the hardware level, only that the dri= ver is requesting a packet.

Wi-Fi hardware implementing 802.11e tends to have four queue= s, each of which is a dumb FIFO, and services only one of them per TXOP (pr= obably the highest priority one). It doesn't even do the "naive&qu= ot; thing you mention - which goes some way to illustrate the point of view= of the typical hardware engineer.

- Jonathan Morton

--001a11393376326375051c31e543--