Damned if I know how or if this is going to work.
---------- Forwarded message ---------- From: Black, David <[email protected]> Date: Tue, Jul 7, 2015 at 8:10 PM Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? To: "[email protected]" <[email protected]> <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: 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. </WG chair hat OFF> Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] 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 [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
