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 2BF8921F985 for ; Mon, 3 Aug 2015 20:26:17 -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 1ZMSrm-0004tf-Kr for make-wifi-fast@lists.bufferbloat.net; Tue, 04 Aug 2015 04:26:15 +0100 Message-ID: <55C030D7.60506@superduper.net> Date: Mon, 03 Aug 2015 20:26:15 -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> <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> In-Reply-To: <5CC1DC90-DFAF-4A4D-8204-16CD4E20D6E3@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable 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:26:46 -0000 BE and BK get a single MPDU, which can be an A-MPDU, which can be up to=20 5.3ms of data, which can be up to 4MBytes (or, much much less). Simon On 7/30/2015 2:35 PM, Sebastian Moeller wrote: > Hi Jonathan, > > nice information about the competing schemes (and I do not consider my = rant a proposed scheme ;) ) > > But looking at https://en.wikipedia.org/wiki/IEEE_802.11e-2005 I learn = that AC_VO gets 1.5ms guaranteed TXOP (roughly air-time), AC_VI gets 3ms = and BE and BK only get a single MSDU. Even assuming this means an A-MSDU= which as far as I can tell reaches up to 8K (in 802.11n, no idea about a= c). If I do the math I see that from roughly 42 Mbps on AC_VO actually ge= ts more airtime than BE and BK, AC_VI by the same logic reaches parity wi= th BK and BE from 21 Mbps on. So for a well set up wifi net both VI and V= O will get preferred media access and a larger bandwidth share, I hope I = misunderstood something, but basically this means that the incentives to = choose the correct AC shift with available bandwidth. So from speeds > 21= Mbp any client or AP should use AC_VI exclusively and above 42 AC_VO, or= do I miss something here (can clients/STAs actually enforce their markin= g or does the AP call the shots)? Anyway, for me it seems that the whole = IEEE 802.11e thing might contain dragons=85 (but most likely I simple do = not grasp the beauty of 802.11e, for all I know it might actually be well= -designed) > > > Best Regards > Sebastian > > On Jul 30, 2015, at 22:29 , Jonathan Morton wro= te: > >>> https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11e/ >>> On the topic of the actual mappings.... >> Here=92s a handy comparison table to show how the draft, CJ=92s sugges= tions, and cake=92s 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 >> AF3x | VI | BE | VI >> CS3 | VI | BE | VI >> AF2x | BE | BE | VI >> CS2 | BE | BE | VI >> AF1x | BK | BE | BE >> 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 =93high=94 cl= asses than either of these suggestions. I also note that cake does inver= t CS4 vs AF4x in a way that CJ doesn=92t like - but perhaps this is mitig= ated 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. >> >> None of these suggestions make any practical distinction between the =93= drop probability=94 divisions within the AFxx classes - even though in so= me cases they are mapped to distinct UP values, these always fall into th= e same major class. I suppose that distinction would be better left to a= n AQM algorithm that was aware of them, which cake is not since I can=92t= immediately see a way to make Codel respond reasonably to it. >> >> The draft doesn=92t address the =93legacy=94 codepoints associated wit= h the old TOS bits, but cake does, so I extended the table accordingly. >> >> I couldn=92t quite decipher Sebastian=92s suggestions into table form,= so I omitted those. >> >> The major =93dangerous=94 feature I see in the draft is the treatment = of CS6 and CS7 traffic - long on =93drop or remark=94 and short on =93if = you must, just stick it in VO". CS6 in particular is used by common NTP = implementations, and for good reason. As far as I=92m concerned, equipme= nt should *not* remark or drop traffic by default based solely on its DSC= P. Indeed, equipment should probably assume they are not acting as the e= dge 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 > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast