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

[Gorry Fairhurst <[e-mail]>]

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