[Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
swmike at swm.pp.se
Sat Jul 18 07:41:17 EDT 2015
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 <david.black at emc.com>
> Date: Tue, Jul 7, 2015 at 8:10 PM
> Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
> To: "tsvwg at ietf.org" <tsvwg at ietf.org>
> <WG chair hat OFF>
> 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:
> 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:
> 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:
> 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:
> 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
> 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.
> </WG chair hat OFF>
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> david.black at emc.com Mobile: +1 (978) 394-7754
> Dave Täht
> worldwide bufferbloat report:
> What will it take to vastly improve wifi for everyone?
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
Mikael Abrahamsson email: swmike at swm.pp.se
More information about the Cerowrt-devel