Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments

[Fred Baker <[e-mail]>]

Thanks, Gorry.

Tim, I'm on vacation. You'll need to handle this. But this is similar to the concern I raised on our call regarding CS6/CS7.

Sent using a machine that autocorrects in interesting ways...

> On May 23, 2017, at 9:19 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> I have some comments on:
> https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02
> 
> and also an observation about the new text in the last revision.
> 
> The top-level observation (I'll follow-up with another email if needed about specific text) is that the latest revision discusses the way in which access points and wireless devices can change the DSCP marking or drop traffic because of the DSCP marking.
> 
> My point is that I do see real benefit in recommendations on how to forward DSCPs across APs and I suspect, if done correctly, this can greatly ease the consistent use of DSCP. I like the way this maps PHBs, and I hope this can allow all equipment to support a well-understood default treatment.
> 
> However, I think the new remarking and drop recommendations in this new version are not helpful in this general context as **general guidance** to manufacturers and users of 802.11 equipment. Although RFC 4594 Section 3.1 (etc) allows a diffserv domain to configure polices at the edge, the types of policy (and security and QoS implications) that are needed depends on the deployment scenario - and I do not see the current rules as being good defaults for all of the wide variety of 802.11 equipment. What works in managed environments in enterprises, public wifi access, isn't what is best when I place it in my home network, use as a layer 2 infrastructure in a very general sense, as a bridge to other layer 2 infrastructure (zigbee, etc), etc.
> 
> I, for one, would not wish to see a plethora of simple APs to implement default dropping of classes they do not have PHB support for and remarking of other packets to what they see as the best DSCP for my traffic - to me, that would really mess-up ability to use diffserv in other segments of the network - and is really quite at odds with what I see is currently possible where most markings are actually being passed through most network links.
> 
> Specifically, I fear the present text could become an impediment to sender marking of DSCP across IP networks in general. I am not even sure this is the correct document to talk about what I would call managed 802.11 networks, but if it reallty is - then I think this needs to be clearly separated from other uses.
> 
> The editorial comments are below,
> 
> best wishes,
> 
> Gorry Fairhurst
> 
> ----
> 
> - rephrase?
> OLD:
> a [RFC3246] EF PHB service
> NEW:
> an EF PHB service [RFC3246]
> 
> - rephrase?
> OLD:
> a [RFC2597] AF PHB service
> MEW:
> an AF PHB service [RFC2597]
> 
> - Comment, if there is no other classification or marking policy
> enforcement point, then this sets the DSCP that will be used
> on the remainder of the Internet path. Could we say that?
> TEXT:
> This derived DSCP value
> is then used for QoS treatment between the wireless access point and
> the nearest classification and marking policy enforcement point
> (which may be the centralized wireless LAN controller, relatively
> deep within the network).
> 
> 
> - Comment, the new text below reads like this is always the case, whereas
> there is now work in the IETF to revise these definitions. I think
> there is value in pointing to the WG ID on this topic as informational,
> and I think we need to reconsider citing “draft-tsvwg-le-phb“
> as well as RFC3662.
> TEXT:
> and causing legitimate business-relevant
> High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for
> which it is not intended
> 
> - Question, is it helpful to insert /present/ before wireless device
> to suggest that this is not necessarily the preferred approach.
> TEXT:
> Most wireless device operating systems generate UP values by the
> same method as described in Section 2.2 (i.e
>