[Cerowrt-devel] Fwd: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e

[Dave Taht]

---------- Forwarded message ----------
From: Cullen Jennings <fluffy at iii.ca>
Date: Thu, Jul 16, 2015 at 12:15 AM
Subject: [tsvwg] Comments on draft-szigeti-tsvwg-ieee-802-11e
To: Tim Szigeti <szigeti at cisco.com>, tsvwg at ietf.org



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.





-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast