[tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?

["Black, David" <[e-mail]>]

<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
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------