[Cake] [Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?

[Mikael Abrahamsson]

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:
>
> 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
> david.black at emc.com        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
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se