Subject: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

From: Cullen Jennings <[email-masked]>
Date: Wed, 15 Jul 2015 16:15:26 -0600

I'm glad to see this draft. This does need to be standardized - just having unpredictable behavior of equipment in the field is very bad. I do think this should be standards track and jointly developed by IEEE and IETF. 

I think the metric for how we choose needs to be based on finding a sane set of defaults that is going to work for the majority of situations and allow many reconfiguration cases for use cases that don't work. There is no mapping that will will work for 100% of use cases.

I'd restructure the draft to simply have figure 4 be an IANA tables that showed the mappings and then have text to explain why the mapping is made the way it is. For me the focus of this draft is the default configuration of devices, I'm assuming that devices can be configured to override the defaults in this specification. 

On  the applicability, it is very hard for an manufacture to know if an access point is going to be on the edge of the middle of the network when they develop the code for it. Even when it is deployed, it is very hard to to know if it is near the edge or not. I would remove the limitations of applicability and make the applicability be the internet.

I'd move all the material about how 802.11e works to an appendix. 

I don't think the network norm has been to move from DSCP to marking with smaller number of bits by taking the high order bits (and visa versa in other direction). I agree some equipment has done this. But this does not really matter this draft, I would remove this type of stuff that is hard to a get agreement on and just focus on the mappings. Similarly I question that multimedia class was intended to necessarily be video. 

The vast majority of the devices that need to implement this will be deployed in situation where they run the default configuration that came from the manufacture so ideas like where the edge of the diff serv domain are can't be used very easily. 

On the topic of the actual mappings....

Based on my view of the changed applicability, I think things like CS6 and 7 need to map to UP 6 or 7 not 0 

Agree that EF -> 6 

We should consider CS5 mapping to same things as EF (6) but should map to at least 5 so that it is not less than the video flows. Note that the voice and signaling (EF and CS5) both have the same top 3 bits for DSCP value and that was by design. Slight rat whole on this topic ... Cisco's first QoS demo of video over sprints network set the QoS for video to be above signaling and you once the video started you could never stop the video or even hang up on the call. Due to a bunch of bugs on that prototype, you basically you had to pull the battery on the phone to get your phone so you could control it again.

The practical use of AF4 vs CS4 for video phone calls has always been confusing.  Over the past 4 years we have spent a huge amount of time getting the direction to be AF4. If this spec put CS4 above AF4, that would be a cause multiple manufactures to re-examin all of that and likely move to CS4 completely reseting the work we have done on this. The one thing I feel really strongly about is CS4 can't map higher than AF4. 

In the actual use of interactive video, some bits are far more important than others and we want to be able to indicate this inside the AF4 class so some should map to 4 and some should map to 5. I would suggest  something like 
AF41 and AF42 map to 5 and AF43 and AF44 map to 4.

Map CS4 to 4

CS3 is particularly tricking. The thing that is tricky about it is it got labeled Broadcast video.  On unmanaged networks running default configurations, it is very unlikely to be broadcast video and is much more likely to be surveillance video. This is probably best mapped to 3 with configuration that allows it to be mapped to 4 instead. Of course there are networks where the surveillance traffic is more important than everything else (same as broadcast video) but if the consumer WIFI camera puts in wireless traffic at UP 5, users will not be happy. As a result, I would make the default mapping for CS3 and AF3 be 3. I know it would be appealing to look at what CS3 was meant to be used for but I think it is more important to think about how it did get used. The case I am thinking of is a wired surveillance camera plugged into a 802.11  bridges that does wireless to another AP than connects to the rest of the internet.

AF2 to 3 or 0. Sure be nice if it went somewhere else but when mapping 64 things to 8, somethings not going to be pretty.  I don't work with this enough to know when to use 3 and when 0. 

My experience is mostly around the audio and video qos so don't really have any comments on CS2 but mapping to 0 seems OK. 

Having AF1 maps to something less that DF seems like it will cause lots of unhappiness and surprises. I'd map it  3 or 0. 

CS1 to 1 makes sense. 

As Ken mentioned, adding the the VOICE-ADMIT admit to 6. 

On dropping things not in use. That's fine as advice to people deploying things but probably not much use to equipment vendors.  It would be nice if all the deployment advice got separated to one section.

---

From: <[email-masked]>
Date: Thu, 16 Jul 2015 08:52:20 +0200

Tim, Cullen,

well written first draft.

-----Cullen wrote-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Cullen Jennings
Betreff: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

   I do think this should be standards track and jointly developed by 
   IEEE and IETF. 

RFC4594 & 5127 and draft-diffserv-intercon all are pure IETF TSVWG turf and they are all informational (Tim, please move the diffs-interc reference). Let's discuss info/standard track issues in Prague.

    [snip]

Thanks for this material. I had the same thought as Cullen, maintain it but move to an appendix.

     I don't think the network norm has been to move from DSCP to 
     marking with smaller number of bits by taking the high order
     bits (and vice versa in other direction). 
     [snip]

Yes, better to remove this (I had related text in my draft too).     

     [snip] Cisco's first QoS demo of video over sprints network 
     set the QoS for video to be above signaling and you once 
     the video started you could never stop the video or even 
     hang up on the call. 

Says that if DSCPs or P-Bits express queuing priorities, then signaling should not be of lower priority than related payload? If yes, a generic statement is useful. 
Other options (certainly not complete): 
- signaling and payload have access to separate resources each.
- signaling is marked AFn1 while related payload is marked AFn2/3.
 
     [snip]
     In the actual use of interactive video, some bits are far 
     more important than others and we want to be able to 
     indicate this inside the AF4 class so some should map to
     4 and some should map to 5. I would suggest  something 
     like AF41 and AF42 map to 5 and AF43 and AF44 map to 4.

Cullen - what is meant by AF44?

     [snip]
     Having AF1 maps to something less that DF seems like 
     it will cause lots of unhappiness and surprises. I'd 
     map it  3 or 0. 

The idea of having "Best Effort" and one class with two subclasses below Best Effort is challenging. Is there an option to define the IEEE Background class as IETF Best Effort and the IEEE Best Effort to mean something like medium low priority? Should we go for a mapping of PHBs by their properties rather than by class name or codepoint? Having said that means I support Cullen's view expressed above. I'd further be happy to have Less Than Best Effort with a standardized DSCP, as there's an issue with CS1.

Regards,

Ruediger

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 23 Jul 2015 06:39:39 +0000

HI Cullen,

Thanks taking the time to review the draft and providing comments. Your feedback is very appreciated.

Some comments inline... (prefaced with [TS]):

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Thursday, July 16, 2015 12:15 AM
To: Tim Szigeti (szigeti); [email-masked]
Subject: Comments on draft-szigeti-tsvwg-ieee-802-11e

[TS] 
Sure. So, as with RFC 4594, this draft aims to provide recommendations (which may be used as defaults); however, having fully customizable mappings is always the most comprehensive option for users.

[TS] 
Yes - if these recommendations are used as defaults, they may be overridden when they do not align to specific requirements/constraints.

[TS] 
Removed and the draft has been correspondingly adapted (v01).

[TS] 
No problem. I'll make that change in the next rev.

[TS] 
OK. No problem. Will do.

[TS] 
Sure. I would argue that in 99%+ of deployment cases, the access point is at the edge of the network providing access (rather than extending the infrastructure); as such, a suitable default would be the former case elaborated in Section 4.1.1 (in v01).

[TS] 
Yes - this change has been added to the AP-to-AP use-case, and added to Section 4.1.1 (in v01). Network Control should be mapped to UP 7 (per 802.11 Table 9-1).

Agree that EF -> 6 

[TS] 
I actually agree. Personally I think Signaling should be mapped to the same class as voice. There is a precedent for this in RFC 5127 Section 4.1. However, I've received a lot of push-back when presenting this recommendation, with objections relating to the fact that Signaling doesn't require the same level of service as Telephony (which is the reason for the compromise expressed in the draft - in Section 4.2.2. I'm willing to make this change, if that's the consensus. Waiting to see on how the discussion goes today at IETF93-TSVWG-II).

[TS] 
Well, that's really a discussion relating to recommendations presented in RFC 4594. Perhaps that RFC needs revisiting, in which case it will have a trickle-down effect on this draft.

In this exercise, I've endeavored to be as neutral and unoriginal as possible, taking the relevant (IETF and IEEE) standards as given and as written, and seeking to reconcile these; not introducing my own preference or interpretation of what these actually "should" say.

[TS] 
That's an interesting take. Not quite fully aligned to what is expressed in RFC 4594. The key point to remember is that with customizable mappings, you can enable such options, should you wish. However, when presenting a standards-based reconciliation, I'm bound to adhere closely to the relevant documents, as written.

Map CS4 to 4

[TS] 
I'd need more rationale here. I've presented a case based on RFC 4594 on why CS4 and CS3 are better mapped to UP 5. 

[TS] 
Again, RFC 4594 clearly expresses that CS3 may receive a superior service to elastic multimedia streams (in fact, this class 'MAY receive a third EF PHB', similar to Real-Time Interactive, which 'MAY receive a second PHB'). These inelastic classes are clearly intended to receive a superior service to the elastic media classes, which is reflected in the mapping in our draft (Section 4.2.3).

[TS] 
Agreed. We make the argument on why AF2 to UP 3 is preferred in Section 4.2.5.

[TS] 
Great.

[TS] 
Well, again -drawing from RFC 4595 (specifically Section 4.8) states:

" The High-Throughput Data service class is RECOMMENDED for elastic
   applications that require timely packet forwarding of variable rate
   traffic sources and, more specifically, is configured to provide good
   throughput for TCP longer-lived flows.  TCP [RFC1633] or a transport
   with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782]
   normally will drive as high a data rate as it can obtain over a long
   period of time."

"It can be assumed that this class will consume any available bandwidth
   and that packets traversing congested links may experience higher
   queuing delays or packet loss."

As such, this High-Throughput Data Service class is considered a 'bandwidth hog' that will consume/rob bandwidth away from both Low-Latency Data and Default Forwarding if left in the same access-category. Inline with the above snippet "this  class... may experience higher queuing delays or packet loss" seems to make it a viable candidate for AC_BK (after all, the *ONLY* difference between AC_BE and AC_BK servicing is 4 slot times: i.e. 36 us to 80 us, depending on implementation). As such, the difference is largely negligible from an overall treatment perspective, but it will service to protect the Low-Latency Data and Default Forwarding traffic classes from this bandwidth hogging traffic class that is largely machine-to-machine traffic.

CS1 to 1 makes sense. 

[TS] 
Done (added in Section 4.2.1 in v01).

[TS] 
Thanks again for the comments and feedback Cullen!

-tim

---

From: "Tim Szigeti (szigeti)" <[email-masked]>
Date: Thu, 23 Jul 2015 06:46:32 +0000

Thank you Ruediger for providing your feedback.

Some comments inline... (preceded by [TS]):

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 16, 2015 8:52 AM
To: [email-masked]; Tim Szigeti (szigeti)
Cc: [email-masked]
Subject: AW: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

Tim, Cullen,

-----Cullen wrote-----
Von: tsvwg [mailto:[email-masked]] Im Auftrag von Cullen Jennings
Betreff: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[TS] 
I'm ok with that - but I don't see how this draft can go in the standards track, when the RFCs that it depends on and is supported by (e.g. 4594, 5127, etc.) are all in the informational track.

[TS] 
Oh man. I really like including DiffServ-Intercon. But let's discuss later today.

    [snip]

[TS] 
Will do. In the next rev.

[TS] 
OK - I'll reword this section in the next rev.

[TS] 
Well, statements in RFC 4594 as well as recommendations in RFC 5127 show signaling as the same level of servicing as media. Such a change would need to be made in those documents, rather than in this one (which depends and draws guidance from those)

     [snip]

     [snip]

The idea of having "Best Effort" and one class with two subclasses below Best Effort is challenging. Is there an option to define the IEEE Background class as IETF Best Effort and the IEEE Best Effort to mean something like medium low priority? 

[TS] 
Well, that would be a good discussion, but would need to be in the IEEE forum. 

This draft takes the standards as written and seeks to reconcile these. If the standards change or evolve, this will have a trickle-down effect on this draft.

Should we go for a mapping of PHBs by their properties rather than by class name or codepoint? Having said that means I support Cullen's view expressed above. I'd further be happy to have Less Than Best Effort with a standardized DSCP, as there's an issue with CS1.

[TS] 
Sure. And if the DSCP associated with Less Than Best Effort changes, I'll amend the draft accordingly.  

Regards,

Ruediger

[TS] 
Thanks again Ruediger!

-tim