Technical Summary
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.
Working Group Summary
This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.
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.
Document Quality
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.
Personnel
The Document Shepherd is David Black.
The responsible Area Director is Spencer Dawkins.
RFC Editor Note
RFC Editor Note
OLD
o Setting a traffic conditioning policy reflective of business
objectives and policy, such that traffic from authorized users
and/or applications and/or endpoints will be accepted by the
network; otherwise packet markings will be "bleached" (i.e.
remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made
it clear that it is generally NOT RECOMMENDED to pass through DSCP
markings from unauthorized and/or unauthenticated devices, as
these are typically considered untrusted sources. This is
especially relevant for IoT deployments, where tens-of-billions of
devices are being connected to IP networks with little or no
security capabilities (making such vulernable to be utilized as
agents for DDoS attacks, the effects of which can be amplified
with preferential QoS treatments, should the packet markings of
such devices be trusted).
NEW
o Setting a traffic conditioning policy reflective of business
objectives and policy, such that traffic from authorized users
and/or applications and/or endpoints will be accepted by the
network; otherwise packet markings will be "bleached" (i.e.
remarked to DSCP DF and/or UP 0). Additionally, Section 5.3 made
it clear that it is generally NOT RECOMMENDED to pass through DSCP
markings from unauthorized and/or unauthenticated devices, as
these are typically considered untrusted sources. This is
especially relevant for IoT deployments, where tens-of-billions of
devices are being connected to IP networks with little or no
security capabilities, leaving them vulnerable to be utilized as
agents for DDoS attacks. These attacks can be amplified
with preferential QoS treatments, should the packet markings of
such devices be trusted.