From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (unknown [IPv6:2001:ba8:1f1:f263::2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3BE0621F97A for ; Mon, 3 Aug 2015 20:16:12 -0700 (PDT) Received: from block9.public.monkeybrains.net ([162.217.75.161] helo=[192.168.128.6]) by masada.superduper.net with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZMSi0-0004oz-KA for make-wifi-fast@lists.bufferbloat.net; Tue, 04 Aug 2015 04:16:10 +0100 Message-ID: <55C02E78.9000300@superduper.net> Date: Mon, 03 Aug 2015 20:16:08 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: make-wifi-fast@lists.bufferbloat.net References: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> In-Reply-To: <356F5FEE-9FBD-4FF9-AC17-86A642D918A4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.9 (--) Subject: Re: [Make-wifi-fast] [Cerowrt-devel] [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 03:16:41 -0000 On 7/30/2015 1:29 PM, Jonathan Morton wrote: >> https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11e/ >> On the topic of the actual mappings.... > Here’s a handy comparison table to show how the draft, CJ’s suggestions, and cake’s current implementation map DSCPs to traffic classes: > > DSCP | SZ | CJ | Cake > --------------------- > CS7 | XX | VO | VO > CS6 | ?? | VO | VO > EF | VO | VO | VO > VA | VO | VO | VO > CS5 | VI | VO | VO > AF4x | VI | VI | VI > CS4 | VI | VI | VO CS4 is for videoconferencing and gaming - this involves bursts of data much larger than pure voice traffic. Putting this in VO will prevent real pure voice traffic being able to achieve truly low latencies. I would also suggest lowering the priority of CS5. > AF3x | VI | BE | VI AF3 is for elastic flows - like TCP, so will use all available bandwidth. VI has significantly higher priority over the air than BE, so will starve other BE flows. This should be BE at most. > CS3 | VI | BE | VI > AF2x | BE | BE | VI > CS2 | BE | BE | VI > AF1x | BK | BE | BE AF1 is described as bulk traffic, and not latency sensitive - in an attempt to achieve some prioritization I believe it should be put in a lower AC than BE, so that BE has some meaningful priority above bulk transfers. I think the draft has it right here. > DF | BE | BE | BE > CS1 | BK | BK | BK > TOS4 | BE | BE | VI > TOS2 | BE | BE | BE > TOS1 | BE | BE | VI > > Interesting to note that cake puts a lot more traffic in “high” classes than either of these suggestions. I also note that cake does invert CS4 vs AF4x in a way that CJ doesn’t like - but perhaps this is mitigated by the fact that cake thresholds VI at three times the bandwidth as VO, which I think is appropriate since video consumes more bandwidth than voice (or games) traffic. Problem is - cake is not operating on other WiFi flows on overlapping WiFi networks - only EDCA is giving priority there. > > None of these suggestions make any practical distinction between the “drop probability” divisions within the AFxx classes - even though in some cases they are mapped to distinct UP values, these always fall into the same major class. I suppose that distinction would be better left to an AQM algorithm that was aware of them, which cake is not since I can’t immediately see a way to make Codel respond reasonably to it. > > The draft doesn’t address the “legacy” codepoints associated with the old TOS bits, but cake does, so I extended the table accordingly. > > I couldn’t quite decipher Sebastian’s suggestions into table form, so I omitted those. > > The major “dangerous” feature I see in the draft is the treatment of CS6 and CS7 traffic - long on “drop or remark” and short on “if you must, just stick it in VO". CS6 in particular is used by common NTP implementations, and for good reason. As far as I’m concerned, equipment should *not* remark or drop traffic by default based solely on its DSCP. Indeed, equipment should probably assume they are not acting as the edge of a network domain unless specifically configured otherwise. > > - Jonathan Morton > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast