Mapping Diffserv to IEEE 802.11
draft-ietf-tsvwg-ieee-802-11-11

Document shepherd write-up:

                    Diffserv to IEEE 802.11 Mapping
                    draft-ietf-tsvwg-ieee-802-11-07

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  As internet traffic is increasingly sourced-from and destined-to
  wireless endpoints, it is crucial that Quality of Service be aligned
  between wired and wireless networks; however, this is not always the
  case by default.  This document specifies a set Differentiated
  Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
  to reconcile the marking recommendations offered by the IETF and the
  IEEE so as to maintain consistent QoS treatment between wired and
  IEEE 802.11 wireless networks.

The WG has requested Proposed Standard status because this draft
specifies guidelines for Diffserv mappings between wired and wireless
networks that are intended to be implemented by wireless endpoints
and access points.  The WG wants to encourage consistent implementation
of this functionality.

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd.  The draft has been significantly modified
as a result, including revising the mappings to resolve concerns about
potential priority inversion between wired and wireless networks.  The
WiFi material has also been reviewed by a WiFi expert.

The mappings in this draft have been stable for about the past year and
are being implemented.  Recent activity on this draft stemming from WG
Last Call has focused on other aspects, primarily security-related (e.g.,
network cannot "trust" DSCP markings set by the originator of traffic)
and related concerns around dealing with possible use and misuse of
the high priority CS6 and CS7 DSCP markings for network control traffic
such as routing protocols.  All of these concerns have been resolved,
and the shepherd is confident that the draft reflects WG rough consensus.

The TSVWG WG is working on revising and replacing the RFC 3662
specification of Lower Effort (less than best effort) Diffserv traffic;
that revision will change the recommended DSCP.  The WG has decided
that this DSCP to UP mapping draft should reflect current "running code"
that uses the CS1 codepoint for Lower Effort traffic and not wait for
completion of work on replacement of RFC 3662 and selection of a new
recommended default DSCP for Lower Effort traffic.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits 2.14.01 reports two Downrefs.  The references to RFC 4594 and
RFC 3662 need to be normative as those documents need to be understood
in order to completely implement these mappings.  It will be necesary to
note these Downrefs during IETF Last Call.

idnits is impossible to completely satisfy wrt RFC 2119.  This draft
uses "NOT RECOMMENDED" as defined by RFC 2119, even though that keyword
is not part of the standard RFC 2119 boilerplate that idnits checks for.

The other two idnits items can be ignored:
- There is no need for a pre-RFC5378 disclaimer; and
- The IEEE 802.11 standard is a fine normative reference.

There are no IANA Considerations.

[Ballot comment]
Please expand the following acronyms upon first use; see
https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance.

- RF - radio frequency
- IPX - Internetwork Packet Exchange
- GSMA-IPX
- BSS
- EIFS
- NVO3

[Ballot comment]
Agree with Mirja's comments, especially the category, I think this should be a BCP.
A BCP is a way to standardize practices and the results of community deliberations.
While the working group noted their desire for PS to "encourage consistent
implementation", this is the definition of a BCP.
A BCP "is designed to be a way to standardize practices" (RFC2026), it is not
informational.

[Ballot comment]
Editorial Comments:

- It might be helpful to make it clear early in the draft that "wireless" means 802.11, not LTE, etc. Section 1.2 sort of does that, but I think there's room for stating it earlier and more strongly.

-1.5: There are a number of lower case instances of "must" and "should". If that is intentional, please consider using the boilerplate from 8174 instead of 2119.

[Ballot comment]
Firstly, I'd like to thank David Black for one of the best shepherd writeups I've seen in a very long time.
I'd also like to thank Sarah Banks for the nice OpsDir writeup.

I had many of the same questions as Mirja - hopefully, they are being addressed/answered.

[Ballot comment]
Two (important) high level comments:

1) I really think this doc should not redefine normative mapping that are already defined in RFC4594. I would srongly recomend to repharse without using normative language and just refer to RFC4594. One example:

OLD
"The RECOMMENDED DSCP marking for Network Control is CS6, per
  [RFC4594] Section 3.2;"
NEW
"The recommended DSCP marking for Network Control is CS6, per
  [RFC4594] Section 3.2;"
OR (you can use a literal citation):
"As stated in [RFC4594], Section 3.2: "The RECOMMENDED DSCP marking [for Network Control] is CS6"."

2) Further, I’m wondering if this document should be rather BCP than Standards Track as it does not define a protocol but gives normative recommendations?

----
Other comments:

1) EIFS is not defined/extended

2)  in sec 4.2.2:

„(as recommended above and following the EDCAF treatment logic described in Section 4.“

maybe s/described in Section 4/described at the beginning of this Section/

I was a bit confused where in section 4 given this text is in section for.


However, maybe it might be good to actually move that paragraph at the beginning of section 4 explaining implementations of UP differentiation somewhere to section 1 or in an own section, as it rather provides background info than making any recommendations.

3) in sec 4.2.5:

„The Multimedia Streaming service class is RECOMMENDED for
  applications that require near-real-time packet forwarding of
  variable rate elastic traffic sources.  Typically these flows are
  unidirectional.“
Not sure if streaming is typically unidirectional, but why is this important here?

4) Sec 5:
„This is RECOMMENDED whenever supported.“

Actually not sure what this means or why it is necessary to say this (normatively).

5) Sec 5.2:

„Therefore, it is NOT RECOMMENDED that wireless access points leverage Layer 2
  [IEEE.802.11-2016] UP markings as set by wireless hosts…“

I think this could be made even stronger and say MUST NOT instead (where NOT RECOMMENDED is a SHOULD NOT)

6) sec 5.3:

„CS6 and CS7 SHOULD NOT be passed through to the wired network in the upstream direction unless…“

Should this maybe also be a „MUST NOT“?

7) Section 6:

I would recommend to actually move the background described here (mainly section 6.1) to an appendix at the end of the doc, given the intro says that. Further, section 6.3 should be moved to an own section (that stays in the body of the document) as it actually provides normative recommendations.
I would further recommend to keep section 6.2 also in the body but move it before section 2 as this is the needed background to understand the terminology in this doc. Respectively terminology that is only used (and explained) in section 6.1 could be removed from section 1.6.

8) Section 8.1

„Policing EF marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246] Section 3.“
This doesn’t appear to be full sentence.

9) Also section 8.1:

„This is especially relevant for IoT deployments, where tens-of-billions of
      devices that may have little or no security are being connected to IP networks.“

I really don’t see why this is more relevant for IoT than other devices that connected to a wifi network. Is this sentence actually needed here?


Also, this document, recommends bleaching, however, isn’t there another DiffServ RFC that discusses forwarding policies that should be references (maybe even instead of making an explicit normative recommendation in this doc)? Maybe RFC8100 (didn’t look it up…)?

10) Also section 8.2:

„… it is RECOMMENDED that all packets marked to Diffserv Codepoints not in use over the wireless network be mapped to UP 0…“

I’m actually not certain what „not in use over the wireless network“ means here. Can you please further specify this!

11) Question regarding section 5.1 and 8.2 respectively: 
I assume e.g. DHCP traffic is not considered as control traffic then? Might be good to state this explicitly… Or should it?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-tsvwg-ieee-802-11-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-09):

From: The IESG
To: IETF-Announce
CC: "David L. Black" , tsvwg@ietf.org, david.black@emc.com, draft-ietf-tsvwg-ieee-802-11@ietf.org, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diffserv to IEEE 802.11 Mapping) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Diffserv to IEEE 802.11
Mapping'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  As internet traffic is increasingly sourced-from and destined-to
  wireless endpoints, it is crucial that Quality of Service be aligned
  between wired and wireless networks; however, this is not always the
  case by default.  This document specifies a set of Differentiated
  Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
  to reconcile the marking recommendations offered by the IETF and the
  IEEE so as to maintain consistent QoS treatment between wired and
  IEEE 802.11 wireless networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc4594: Configuration Guidelines for DiffServ Service Classes (Informational - IETF stream)
    rfc3662: A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services (Informational - Independent Submission Editor stream)

Document shepherd write-up:

                    Diffserv to IEEE 802.11 Mapping
                    draft-ietf-tsvwg-ieee-802-11-07

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


  As internet traffic is increasingly sourced-from and destined-to
  wireless endpoints, it is crucial that Quality of Service be aligned
  between wired and wireless networks; however, this is not always the
  case by default.  This document specifies a set Differentiated
  Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
  to reconcile the marking recommendations offered by the IETF and the
  IEEE so as to maintain consistent QoS treatment between wired and
  IEEE 802.11 wireless networks.

The WG has requested Proposed Standard status because this draft
specifies guidelines for Diffserv mappings between wired and wireless
networks that are intended to be implemented by wireless endpoints
and access points.  The WG wants to encourage consistent implementation
of this functionality.

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd.  the draft has been significantly modified
as a result, including revising the mappings to resolve concerns about
potential priority inversion between wired and wireless networks.  The
WiFi material has also been reviewed by a WiFi expert.

The mappings in this draft have been stable for about the past year and
are being implemented.  Recent activity on this draft stemming from WG
Last Call has focused on other aspects, primarily security-related (e.g.,
network cannot "trust" DSCP markings set by the originator of traffic)
and related concerns around dealing with possible use and misuse of
the high priority CS6 and CS7 DSCP markings for network control traffic
such as routing protocols.  All of these concerns have been resolved,
and the shepherd is confident that the draft reflects WG rough consensus.

The TSVWG WG is working on revising and replacing the RFC 3662
specification of Lower Effort (less than best effort) Diffserv traffic;
that revision will change the recommended DSCP.  The WG has decided
that this DSCP to UP mapping draft should reflect current "running code"
that uses the CS1 codepoint for Lower Effort traffic and not wait for
completion of work on replacement of RFC 3662 and selection of a new
recommended default DSCP for Lower Effort traffic.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits 2.14.01 reports two Downrefs.  The references to RFC 4394 and
RFC 3662 need to be normative as those documents need to be understood
in order to completely implement these mappings.  It will be necesary to
note these Downrefs during IETF Last Call.

idnits is impossible to completely satisfy wrt RFC 2119.  This draft
uses "NOT RECOMMENDED" as defined by RFC 2119, even though that keyword
is not part of the standard RFC 2119 boilerplate that idnits checks for.

The other two idnits items can be ignored:
- There is no need for a pre-RFC5378 disclaimer; and
- The IEEE 802.11 standard is a fine normative reference.

There are no IANA Considerations.

This email announces a TSVWG Working Group Last Call (WGLC) on:

            DiffServ to IEEE 802.11 Mapping
            draft-ietf-tsvwg-ieee-802-11-01
            https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01

This WGLC will last for about 2 weeks weeks.

Comments should be sent to the tsvwg@ietf.org list, although purely
editorial comments may be sent directly to the authors. Please cc: the
WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-ieee-802-11-01

Thanks,
Gorry
(TSVWG Co-Chair)

This email announces a TSVWG Working Group Last Call (WGLC) on:

            DiffServ to IEEE 802.11 Mapping
            draft-ietf-tsvwg-ieee-802-11-01
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11-01

This WGLC will last for about 2 weeks weeks.

Comments should be sent to the tsvwg@ietf.org list, although purely
editorial comments may be sent directly to the authors. Please cc: the
WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-ieee-802-11-01

Thanks,
Gorry
(TSVWG Co-Chair)

This email announces a TSVWG Working Group Last Call (WGLC) on the following targeting publication asa PS:

            DiffServ to IEEE 802.11 Mapping
            draft-ietf-tsvwg-ieee-802-11
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11

This WGLC will last for about 2 weeks weeks.

Comments should be sent to the tsvwg@ietf.org list, although purely
editorial comments may be sent directly to the authors. Please cc: the
WG chairs at tsvwg-chairs@ietf.org  if you would like the chairs to
track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on
draft-ietf-tsvwg-ieee-802-11.

Thanks,
Gorry
(TSVWG Co-Chair)