I agree, that's why I have suggested they use CS0 and have new DSCP patterns (not currently standardized) and use 000xx0 where xx discerns different priority, one being scavanger, one being slightly higher BE (BE+ perhaps) and then one could assure the BE+ got 60% of the bw, BE got 30%, and BE- (the scavanger class) wasn't assured more than 10% of the bw. This would have higher chance of being incrementally deployable than any of the below suggestions. On Sat, 18 Jul 2015, Dave Taht wrote: > Damned if I know how or if this is going to work. > > > ---------- Forwarded message ---------- > From: Black, David > Date: Tue, Jul 7, 2015 at 8:10 PM > Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? > To: "tsvwg@ietf.org" > > > > > This message is written as an individual contributor to engender > some discussion on this topic prior to the TSVWG meetings in Prague. > > A significant concern with the WebRTC QoS draft is the large number > of DSCPs that it uses - see Table 1 in Section 5 of the draft: > > https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-04#section-5 > > The WebRTC QoS draft references RFC 4594, which is the foundational > RFC on overall application of Diffserv to various types of traffic. > > However, RFC 4594: > > a) is a "Guidelines" RFC, not a "Requirements" RFC; > b) is not standards track for some very good reasons, so > the reference to it is a downref; and > c) explicitly anticipates deployment of subsets of its > classes in the introduction to the RFC. > > Some more recent relevant guidance can be found in the DART draft > that was approved by the IESG last year: > > https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10 > > Based on that draft, here are a couple of specific concerns that > apply to Table 1 in the WebRTC QoS draft: > > - The use of CS1 for Lower Effort (less than best effort) QoS is on > shaky ground at best. See the discussion here: > > https://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-10#page-9 > > Also, a discussion on what to do about Diffserv Lower Effort > (less than best effort) a/k/a Scavenger class QoS is planned > for TSVWG in Prague. IMHO, there is a good 20/20 hindsight > (NB: hindsight) argument to be made that CS1 was the wrong > Default DSCP to use. > > - For data, the WebRTC QoS draft uses four different sets of DSCPs > across which there are no constraints on reordering: > > | Data | CS1 | DF | AF1x (10, | AF2x (18, | > | | (8) | (0) | 12, 14) | 20, 22) | > > This is asking for trouble if all the data involved flows over a > single SCTP association ... which appears to be exactly what WebRTC > is going to do: > > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6 > > Something is definitely wrong here, as the DART draft clearly advises > against more than one DSCP per SCTP association (from Section 6): > > o Should use a single DSCP for all packets within a reliable > transport protocol session (e.g., TCP connection, SCTP > association) or DCCP connection (see Section 5.1 and Section 5.3). > For SCTP, this requirement applies across the entire SCTP > association, and not just to individual streams within an > association. > > Please note that both the DART draft and draft-ietf-rtcweb-data-channel > are IESG-approved and at the RFC Editor. > > In contrast, I think the 9 boxes in Table 1 of WebRTC QoS draft for > Audio, Interactive Video, and Non-Interactive Video across the Low, > Medium and High API priorities are probably ok, although I think there > needs to be a much stronger warning about confining a media flow to > a single API priority, especially Low (based on the selected DSCPs, > mixing Medium with High in a single type of media flow is ok, but Low > SHOULD NOT be mixed with anything else). > > I think that those 9 boxes are the core of the WebRTC QoS draft, so I'm > not suggesting a "tear it up and start over" approach, but I cannot > support an assertion that the table in Section 5 of the WebRTC QoS is > solidly grounded in IETF Diffserv RFCs. > > > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > > -- > 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 > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Mikael Abrahamsson email: swmike@swm.pp.se