Re: [tsvwg] draft-ietf-tsvwg-nqb, more questions

[Greg White <[e-mail]>]

Dave,

Thanks for these thoughts.  I agree that a better solution for NQB is to have the WiFi devices *actually* support the NQB PHB (or support fq_* if that is what you prefer), as opposed to putting NQB traffic into a separate Access Category.   That is essentially the default recommendation of the draft (i.e. support the actual requirements in the draft), even though it doesn't explicitly mention WiFi in that context.  This discussion is more about interoperability with existing WiFi gear that does not support the PHB.   

BTW, our experiments have shown that .11ac implementations actually do a pretty good job at implementing WMM (some better than others).  But I've heard anecdotally about older gear that suffers from priority inversions, etc.

-Greg


On 11/7/19, 3:25 PM, "Dave Taht" <[e-mail]> wrote:

    
    I'm not sure if I should weigh in here or not. A couple notes...
    
    802.11e was seemingly a good idea in 2004, when men were men, APs
    scarce, and txops limited to about 3000/sec.
    
    802.11n added packet aggregation, and 802.11ac added ever more
    dense encodings to wedge even more data into that txop...
    
    but the limiting factor for wifi - particularly in dense environments
    with a range of standards being broadcast remains that fatal 3000
    txops/sec - and while that's a little mitgated by mu-mimo and with
    wifi 6 in ofdma mode made MUCH better, having to be backward compatible
    elsewhere still messes things up.
    
    furthermore, in 802.11n the VO queue cannot aggregate. 700usec lost
    on a single packet.
    
    Use of the VI queue was often buggy in 802.11n chipsets at least as
    far back as 2014 when I last poked into it. The main tested paths
    have generally been BE, BK, and to a small extent VO.
    
    I've got plenty of data showing that it's in general better (from the
    AP's standpoint) to well multiplex and fully fill as best as possible
    just the BE queue for each station, to ignore 802.11e, and to try to
    manage the max txop size in BE in proportion to the load.
    
    We pointed to that result in "ending the anomaly".
    
    and 802.11e scales ever more badly to ever more devices.
    
    From the stations standpoint, it can be (if lightly used) to still
    use the 802.11e stuff, but that should at best be sparingly used.
    
    Some (mostly enterprise) wifi routers do fiddle with the edca params
    some, in particular it does make sense at higher workloads to clamp the
    size of txops to stations are allowed to transmit (via the beacon), and
    I wish more wifi routers did that.
    
    But trying to actively use the 802.11e priorities at this late date,
    not huge on it. Twiddling edca extensively seems like an especially bad idea.
    
    That said, I've been meaning to dig up my old work on the subject,
    look at it in light of modern conditions, but given that most of
    my aircaps still see some wireless-g APs helping mess up things up,
    don't think I have huge reasons to change my current take on it.
    
    I guess my core takeway I'd like people to think about is txops/sec
    relative to how much data can be stuffed into a txop, in the real world,
    rather than trying to make 802.11e do anything useful.