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

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 15 Mar 2016 19:02:20 +0000

> From: <[email-masked]>
> Subject: New Version Notification for draft-szigeti-tsvwg-ieee-802-11-01.txt
> Date: March 15, 2016 at 11:28:58 AM PDT
> To: Fred Baker <[email-masked]>, Tim Szigeti <[email-masked]>
> 
> 
> A new version of I-D, draft-szigeti-tsvwg-ieee-802-11-01.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-szigeti-tsvwg-ieee-802-11
> Revision:	01
> Title:		Guidelines for DiffServ to IEEE 802.11 Mapping
> Document date:	2016-03-14
> Group:		Individual Submission
> Pages:		27
> URL:            https://www.ietf.org/internet-drafts/draft-szigeti-tsvwg-ieee-802-11-01.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-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-szigeti-tsvwg-ieee-802-11-01
> 
> 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: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Mon, 28 Mar 2016 22:38:12 +0000

Hi TSVWG,

As the majority of clients connecting to IP networks are doing so via WLANs, and since IEEE recommendations for QoS do not align with IETF recommendations, it would be highly beneficial to have an IETF-endorsed reconciliation between IETF IP QoS and IEEE WMM QoS, which is the intent of draft-szigeti-tsvwg-ieee-802-11.

Apple, Cisco and other vendors are all planning on developing solutions in the coming months based on a consistent IETF-ratified set of QoS mappings. If you have stake/opinion/feedback in making sure that QoS is handled correctly at wired/wireless edges, then please read the draft and help us pass this through.

https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11-00

[Otherwise, the only guidance in this area is based on non-IETF recommendations (e.g. GSMA <--> WMM)]

Thanks in advance.

-tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2016 8:36 AM
To: Fred Baker (fred)
Cc: [email-masked]; Tim Szigeti (szigeti)
Subject: Re: Fwd: [tsvwg] New Version Notification for draft-szigeti-tsvwg-ieee-802-11-01.txt

True. This will appear on the draft agenda. We will need to get some people sufficiently excited to allocate some cycles to read and continue to comment on the draft.

I'm assuming you'll ask for adoption (which seems reasonable). At which point I'll ask who has read or plans to read this? Let's hope the room is not deadly quiet. We'll move on from there.

gorry

> I haven't heard anything from  you...
>
> Please consider this a request for an agenda slot.
>
>> Begin forwarded message:
>>
>> From: "Fred Baker (fred)" <[email-masked]>
>> Subject: [tsvwg] Fwd: New Version Notification for 
>> draft-szigeti-tsvwg-ieee-802-11-01.txt
>> Date: March 15, 2016 at 12:02:20 PM PDT
>> To: "[email-masked]" <[email-masked]>
>>
>>> has been successfully submitted by Fred Baker and posted to the IETF 
>>> repository.
>>>
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-szigeti-tsvwg-ieee-802-11
>>> -01.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-01
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-szigeti-tsvwg-ieee-802-11-01
>>>
>>> Abstract:
>>>  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: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 28 Mar 2016 22:40:10 +0000

I think you meant https://tools.ietf.org/html/draft-szigeti-tsvwg-ieee-802-11-01 :-)

> On Mar 28, 2016, at 3:38 PM, Tim Szigeti (szigeti) <[email-masked]> wrote:
> 
> Hi TSVWG,
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Mar 2016 11:51:05 -0400

out of curiosity, am I the only one who is still bothered by
labeling/equating DiffServ with QoS (vs Cos)?

Asked another way, does this group still differentiate between QoS and
CoS (service level) as it once did?

Thanks,
Lou

On March 28, 2016 6:38:44 PM "Tim Szigeti (szigeti)" <[email-masked]>
wrote:

> Hi TSVWG,
>
> As the majority of clients connecting to IP networks are doing so via 
> WLANs, and since IEEE recommendations for QoS do not align with IETF 
> recommendations, it would be highly beneficial to have an IETF-endorsed 
> reconciliation between IETF IP QoS and IEEE WMM QoS, which is the intent of 
> draft-szigeti-tsvwg-ieee-802-11.
>
> Apple, Cisco and other vendors are all planning on developing solutions in 
> the coming months based on a consistent IETF-ratified set of QoS mappings. 
> If you have stake/opinion/feedback in making sure that QoS is handled 
> correctly at wired/wireless edges, then please read the draft and help us 
> pass this through.
>
> True. This will appear on the draft agenda. We will need to get some people 
> sufficiently excited to allocate some cycles to read and continue to 
> comment on the draft.
>
> I'm assuming you'll ask for adoption (which seems reasonable). At which 
> point I'll ask who has read or plans to read this? Let's hope the room is 
> not deadly quiet. We'll move on from there.
>
> gorry
>

---

From: "Agarwal, Anil" <[email-masked]>
Date: Tue, 29 Mar 2016 16:53:31 +0000

I wonder why we have not found a reason to use a non-zero DSCP value for DNS packets.
This draft does not mention DNS.
RFC 4594 suggests using DSCP = DF = 0.

Anil

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Tim Szigeti (szigeti)
Sent: Monday, March 28, 2016 6:38 PM
To: [email-masked]
Subject: [tsvwg] FW: Fwd: New Version Notification for draft-szigeti-tsvwg-ieee-802-11-01.txt

Hi TSVWG,

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D00&d=BQIFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=9ZLvTSIJ7vViNIjFwJVUcu_rkMgQAETtdd9_L7tyEeo&e= 

Thanks in advance.

-tim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2016 8:36 AM
To: Fred Baker (fred)
Cc: [email-masked]; Tim Szigeti (szigeti)
Subject: Re: Fwd: [tsvwg] New Version Notification for draft-szigeti-tsvwg-ieee-802-11-01.txt

gorry

>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11&d=BQIFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=yUc8E8p6BcX9BI1TLhtlw_6ayIYCvbL5dEcOz1wukdI&e= 
>>> -01.txt
>>> Status:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11_&d=BQIFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=gPewTn7qnPI4-4fppKtA4ZS_Ofmx06hVJOtMl4-bp3o&e= 
>>> Htmlized:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D01&d=BQIFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=hCedeeOVDF6-XVyszl1t24DJUhtReOAIS0boFU81WAY&e= 
>>> Diff:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D01&d=BQIFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=4E_ZaOCzjpImcajsVRJ32Z82lJnJ0iO5NpRsBJMspLo&e= 
>>>
>>> Abstract:

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 29 Mar 2016 17:06:55 +0000

> On Mar 29, 2016, at 9:53 AM, Agarwal, Anil <[email-masked]> wrote:
> 

Have we demonstrated a requirement for DNS to use a non-default service? I'm unaware of one...

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Tue, 29 Mar 2016 19:58:32 +0000

Yes - RFC 4594 recommends DNS to be serviced with DF; our draft takes RFC 4594 recommendations as a given / starting point.

-tim

-----Original Message-----
From: Fred Baker (fred) 
Sent: Tuesday, March 29, 2016 10:07 AM
To: Agarwal, Anil
Cc: Tim Szigeti (szigeti); [email-masked]
Subject: Re: [tsvwg] New Version Notification for draft-szigeti-tsvwg-ieee-802-11-01.txt

> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht
> ml_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D00&d=BQIFAg&c=jcv3orpCs
> v7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW9uSbnxdNS
> heSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s=9ZLvTSIJ7vV
> iNIjFwJVUcu_rkMgQAETtdd9_L7tyEeo&e=
> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_i
>>>> nternet-2Ddrafts_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11&d=BQIFAg
>>>> &c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBT
>>>> dviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJb
>>>> mVCE&s=yUc8E8p6BcX9BI1TLhtlw_6ayIYCvbL5dEcOz1wukdI&e=
>>>> -01.txt
>>>> Status:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ie
>>>> tf.org_doc_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11_&d=BQIFAg&c=jc
>>>> v3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWI
>>>> W9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&
>>>> s=gPewTn7qnPI4-4fppKtA4ZS_Ofmx06hVJOtMl4-bp3o&e=
>>>> Htmlized:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org
>>>> _html_draft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D01&d=BQIFAg&c=jcv
>>>> 3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCPjbBTdviWIW
>>>> 9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx1oJbmVCE&s
>>>> =hCedeeOVDF6-XVyszl1t24DJUhtReOAIS0boFU81WAY&e=
>>>> Diff:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_r
>>>> fcdiff-3Furl2-3Ddraft-2Dszigeti-2Dtsvwg-2Dieee-2D802-2D11-2D01&d=BQ
>>>> IFAg&c=jcv3orpCsv7C4ly8-ubDob57ycZ4jvhoYZNDBA06fPk&r=FyvaklKYrHaSCP
>>>> jbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=Clq-IzF9qeDd5yZLQyA8KmtL4psfk3_WDpx
>>>> 1oJbmVCE&s=4E_ZaOCzjpImcajsVRJ32Z82lJnJ0iO5NpRsBJMspLo&e=
>>>> 
>>>> Abstract:
>>>> 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:
>>>> autonomous standards-  body, the IEEE, administers the standards 
>>>> for wireless 802.11  networks.  The purpose of this document is to

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 29 Mar 2016 20:12:51 +0000

To my knowledge, there is no RFC updating RFC 2475 to change the definition.

I'll note that there is a fairly fundamental difference between QoS and CoS, at least as implemented in various standards. Your term "service level" is telling in that regard. CoS, as described in IEEE 802.1 P/Q, is a very strict priority service - traffic in one service class is serviced before traffic in the next. QoS, as described in Diffserv, identifies an SLA. That SLA is not necessarily hierarchical; I might have many traffic streams that each have a specified upper bound or lower bound rate (given that there is traffic there to use it) but enjoy no priority with respect to each other. RFC 4594 attempts to clarify issues along those lines - priority is used to limit jitter, rate-based scheduling is used to manage rate, traffic that exceeds a stated rate might be remarked or dropped outright, and so on.

Yes, as far as I know, we haven't gutted diffserv.

> On Mar 29, 2016, at 8:51 AM, Lou Berger <[email-masked]> wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Tue, 29 Mar 2016 16:28:27 -0400

Fred,
    Thanks for the response.

On 3/29/2016 4:12 PM, Fred Baker (fred) wrote:
> I'll note that there is a fairly fundamental difference between QoS and CoS, at least as implemented in various standards. Your term "service level" is telling in that regard. CoS, as described in IEEE 802.1 P/Q, is a very strict priority service - traffic in one service class is serviced before traffic in the next. QoS, as described in Diffserv, identifies an SLA. 
umm, I always read rfc2475 as carefully avoiding saying DiffServ
provides QoS or that its SLAs=QoS.  Now it certainly says DiffServ is
mapped to link-level (and implicitly interface) QoS  mechanisms, but
these aren't the same thing as saying DiffServ delivers QoS -- it
delivers Differentiated services ;-)

> That SLA is not necessarily hierarchical; I might have many traffic streams that each have a specified upper bound or lower bound rate (given that there is traffic there to use it) but enjoy no priority with respect to each other. RFC 4594 attempts to clarify issues along those lines - priority is used to limit jitter, rate-based scheduling is used to manage rate, traffic that exceeds a stated rate might be remarked or dropped outright, and so on.
no disagreement here.
> Yes, as far as I know, we haven't gutted diffserv.
sure, but I think saying QoS=DiffServ guts QoS...

Lou