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

[Brian E Carpenter <[e-mail]>]

David,

Thanks. That expresses exactly what I think, so I really have little
to add.

Expecting more than a very small number of DSCPs and PHBs to work
across ISP boundaries is highly unrealistic, and misusing CS1 is
a pathway to failure.

Regards
   Brian

On 08/07/2015 06:10, Black, David wrote:
> <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]
> ----------------------------------------------------
> 
>