Subject: [tsvwg] FW: New Version Notification for draft-szigeti-tsvwg-ieee-802-11-00.txt

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Tue, 13 Oct 2015 16:46:40 +0000

I wanted to summarize the changes to this latest draft:

Date:		13-Jul-15
Source:		Ken Carlberg
Comment:	Add EF-Admit (RFC 5865) to Telephony Mapping Recommendations
Response:	Done - added to Section 4.2.1 & 4.3

Date: 		13-Jul-15
Source:		Ken Carlberg
Comment:	Split apart current defaults from recommendations (wording recommendations)
Response:	Reworded Section 4.2.1 per suggestions

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Move all 802.11 overview material to an appendix
Response:	Done - moved what was Section 2 (at the front) to Section 6 (at the back, as an appendix)

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Explicitly mention that devices should be able to override the recommendations offered in this draft
Response:	Done - added a new Section 3 to identify the capabilities that wireless access points + devices should support,
		Explicitly including mention that both should be able to perform "fully configurable mappings between DSCP and UP" and that
		"these mapping recommendations [presented in the draft] are not expected to fit every last deployment model,
		 and as such may be overridden by network administrators, as needed"

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	It's hard for a manufacturer to know if their device is deployed on the edge or not - so change recommendation (of CS6 ->UP 0)
Response:	Done - changed the recommendation in Section 4.1.1 and in the Applicability Statement (Section 1.2)

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Reword Section 3.1 that "networking industry norm is to map 3 MSB of DSCP to UP"
Response:	Done - reworded Sections 2.1 and 2.2 to describe this as "a common practice in the networking industry" (rather than "networking industry norm")

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Several comments pertaining to RFC 4594-recommendations vs. recommendations specific to this draft (which accepts and depends on RFC 4594)
Response:	Defer to RFC 4594-bis discussion; if RFC 4594 changes, then this draft must correspondingly change 

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Objection to the recommendation that Bulk/AF1 SHOULD map to UP 2 and thus to the Background Access Category (AC_BK), which is a less-than-best-effort service
Response:	Changed the recommendation in Section 4.2.6 to Bulk MAY map to UP 0 (Best Effort AC) or Bulk MAY be mapped to UP 2 (Background AC),
		"the mapping chosen will depend on business-requirements and/or administrative -preference"

Date:		15-Jul-15
Source:		Cullen Jennings
Comment:	Add EF-Admit (RFC 5865)
Response:	Done - added to Section 4.2.1 & 4.3

Date:		15-Jul-15
Source:		Ruediger Geib
Comment:	Move all 802.11 overview material to an appendix
Response:	Done - moved what was Section 2 (at the front) to Section 6 (at the back, as an appendix)

Date:		15-Jul-15
Source:		Ruediger Geib
Comment:	Reword Section 3.1 that "networking industry norm is to map 3 MSB of DSCP to UP"
Response:	Done - reworded Sections 2.1 and 2.2 to describe this as "a common practice in the networking industry" (rather than "networking industry norm")

Date:		15-Jul-15
Source:		Ruediger Geib
Comment:	Several comments pertaining to RFC 4594-recommendations vs. recommendations specific to this draft (which accepts and depends on RFC 4594)
Response:	Defer to RFC 4594-bis discussion; if RFC 4594 changes, then this draft must correspondingly change

Date:		15-Jul-15
Source:		Ruediger Geib
Comment:	Recommend against having 2 classes serviced "less-than-best-effort" (i.e. Bulk should not map to AC_BK)
Response:	Changed the recommendation in Section 4.2.6 to Bulk MAY map to UP 0 (Best Effort AC) or Bulk MAY be mapped to UP 2 (Background AC),
		"the mapping chosen will depend on business-requirements and/or administrative -preference"

Date:		22-Jul-15
Source:		TSVWG-93 Session 6.4 (and corresponding minutes)
Comment:	Several comments objecting to the recommendation that Bulk/AF1 SHOULD map to AC_BK
Response:	Changed the recommendation in Section 4.2.6 to Bulk MAY map to UP 0 (Best Effort AC) or Bulk MAY be mapped to UP 2 (Background AC),
		"the mapping chosen will depend on business-requirements and/or administrative -preference"

Date:		22-Jul-15
Source:		TSVWG-93 Session 6.4 (and corresponding minutes)
Comment:	Solicit input and guidance for dealing with gaming traffic
Response:	Some gaming apps mark traffic to EF; others to CS2, etc.  In other words, it's all over the map - however:
		RFC 4594 already addresses the recommendations for gaming traffic: 
		Specifically (in Sections 2.1, 2.2, 2.3 and 4.4) RFC 4594 recommends that gaming traffic SHOULD be marked CS4 (Real-Time Interactive)
		Therefore, as this draft accepts and depends on RFC 4594 recommendations, this recommendation will be followed (gaming -> CS4)
		Thus Section 4.2.3 of this draft has been updated to include explicit mention of gaming traffic
		and recommends that (along with the rest of the Real-Time Interactive applications), gaming traffic SHOULD map to UP 5
		(provided gaming is considered relevant; otherwise gaming traffic MAY be serviced in the Scavenger class and mapped to UP 1, per Section 4.2.8)

Date:		22-Jul-15
Source:		TSVWG-93 Session 6.4 (and corresponding minutes)
Comment:	Request to include information about QoS mapping communication between AP and devices (i.e. 802.11u)
Response:	Done - added a new Section (6.3) to the Appendix to overview this amendment to 802.11
		Also added recommendations on how to leverage this feature in line with the mapping recommendations presented in this draft

Date:		17-Aug-15
Source:		Ken Carlberg
Comment:	Add a table for DSCP to 802.1Q/p Mapping
Response:	Seems out-of-scope for the stated purpose of this draft (DSCP to 802.11 Mapping); perhaps another document is needed for DSCP-to-802.1 Mapping?

Date:		11-Oct-15
Source:		IETF Nits Tool
Comment:	Document uses the phrase "NOT RECOMMENDED" but does not include this phrase in RFC 2119 key words list
Response:	Done - amended Section 1.4 "Requirements Language"

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 12, 2015 4:13 PM
To: Fred Baker (fred); Tim Szigeti (szigeti)
Subject: New Version Notification for draft-szigeti-tsvwg-ieee-802-11-00.txt

A new version of I-D, draft-szigeti-tsvwg-ieee-802-11-00.txt
has been successfully submitted by Fred Baker and posted to the IETF repository.

Name:		draft-szigeti-tsvwg-ieee-802-11
Revision:	00
Title:		Guidelines for DiffServ to IEEE 802.11 Mapping
Document date:	2015-10-12
Group:		Individual Submission
Pages:		26
URL:            https://www.ietf.org/internet-drafts/draft-szigeti-tsvwg-ieee-802-11-00.txt
Status:         https://datatracker.ietf.org/doc/draft-szigeti-tsvwg-ieee-802-11/
Htmlized:       https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11-00

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 is due to the fact that two independent
   standards bodies provide QoS guidance on wired and wireless networks:
   specifically, the IETF specifies standards and design recommendations
   for wired IP networks, while a separate and autonomous standards-
   body, the IEEE, administers the standards for wireless 802.11
   networks.  The purpose of this document is to propose a set
   Differentiated Services Code Point (DSCP) to IEEE 802.11 User
   Priority (UP) mappings to reconcile the marking recommendations
   offered by these two standards bodies, and, as such, to optimize
   wired-and-wireless interconnect QoS.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: ken carlberg <[email-masked]>
Date: Wed, 14 Oct 2015 08:45:55 -0400

> On Oct 13, 2015, at 12:46 PM, Tim Szigeti (szigeti) <[email-masked]> wrote:
> 
<snip> 
</snip>
> Response:	Seems out-of-scope for the stated purpose of this draft (DSCP to 802.11 Mapping); perhaps another document is needed for DSCP-to-802.1 Mapping?

if the authors and group feel more comfortable keeping the scope as is (i.e., DSCP to 802.11 mapping), I’m quite happy to go with the flow.  But, I would appreciate/encourage another document on DSCP 802.1 mapping given the recent work from the SIP Forum and ATIS Task Force on the IP NNI.

-ken

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 14 Oct 2015 13:01:28 +0000

> On Oct 14, 2015, at 6:45 AM, ken carlberg <[email-masked]> wrote:
> 
> 

I think the analysis winds up similar, but for example DF wants to be in 802.1 class 1 and scavenger in class 0, as they are strict linear priorities. And you get pretty quickly into the basic issue of priority - folks' big issues take priority, and everyone has different issues. We can discuss in Yokohama, may I suggest?

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 12 Oct 2015 23:15:03 +0000

FYI, this has been posted.

We changed the name from 802.11e to 802.11, as IEEE has similarly changed the name. Hence, rather than being version -02, it is -00. Tim will post a note discussing updates later tonight.

Chairs, please note that we'd like a discussion slot in Yokohama.

> Begin forwarded message:
> 
> From: <[email-masked]>
> Date: October 12, 2015 at 4:13:12 PM PDT
> To: Fred Baker <[email-masked]>, Tim Szigeti <[email-masked]>
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>