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

From: "Black, David" <[email-masked]>
Date: Tue, 7 Jul 2015 18:10:54 +0000

<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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Jul 2015 09:13:03 +1200

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Jul 2015 15:33:48 +0200

David,

draft-ietf-rtcweb-transport put in this language after discussing
reordering:

   Implementations SHOULD attempt to set QoS on the packets sent,
   according to the guidelines in [I-D.ietf-tsvwg-rtcweb-qos].

.....

   All packets carrying data from the SCTP association supporting the
   data channels MUST use a single DSCP code point.

   All packets on one TCP connection, no matter what it carries, MUST
   use a single DSCP code point.

What codepoint to pick is a good question (the one reflecting the
highest priority channel currently being sent is an obvious, but perhaps
not optimal choice).

RTCWEB considered the option of supporting multiple SCTP channels, then
decided not to pursue that option - it just got a bit too messy.

This may or may not help, but should be considered in the discussion on
Wednesday.

Harald

---

From: "Black, David" <[email-masked]>
Date: Sat, 18 Jul 2015 08:38:41 +0000

Harald,
[+rtcweb list]

> This may or may not help, but should be considered in the discussion on

That should help, although I wonder about larger API concerns - my initial
take is that the first JavaScript application API call that sends data
traffic is likely to set the DSCP for the data channel for all data traffic
for the RTCWEB session (or that DSCP will be a browser implementation
constant, in which case, only DF appears to be defensible in full generality,

> decided not to pursue that option - it just got a bit too messy.

In contrast, the DSCP for audio/video traffic can vary within an RTCWEB session.

Meanwhile, on multiple SCTP channels, I've heard *exactly* the opposite from
Cullen.  I've already "volunteered" to show up in RTCWEB's second session on
Friday to talk about the QoS draft (Paul, Cullen and I have talked - we think
we know what has to be done, and hope to have draft text by Thu [and TSVWG
currently has the rtcweb-qos draft on our Thu agenda, not Wed]).

Could you and/or Cullen make sure that Diffserv/DSCP QoS in general and
this multiple SCTP channel concern get onto RTCWEB's Friday agenda when
that agenda gets bashed, please, as I really should be in TAPS during
RTCWEB's Thu session?

Thanks,
--David

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Thursday, July 16, 2015 9:34 AM
> To: Black, David; [email-masked]
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 18 Jul 2015 11:48:50 +0200

On 07/18/2015 10:38 AM, Black, David wrote:
> IMHO),

If we can agree on and document what browsers *should* do, it is likely
that this is what they'll end up doing. The implementors are in the
room, after all.

>  especially as:

Yep. Both because tsvw-rtcweb-qos specifies multiple DSCP code points
per priority level, and because the API as currently designed permits
changing the priority of a media track.

> currently has the rtcweb-qos draft on our Thu agenda, not Wed]).

Thanks for the fix! (was wrong in my notes)
> that agenda gets bashed, please, as I really should be in TAPS during

Cullen's one of the chairs, I'm just a WG member; I'll try to help get
it there.

-- 
Surveillance is pervasive. Go Dark.