* Re: [Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
2015-07-18 8:41 ` [Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? Dave Taht
@ 2015-07-18 11:41 ` Mikael Abrahamsson
0 siblings, 0 replies; 2+ messages in thread
From: Mikael Abrahamsson @ 2015-07-18 11:41 UTC (permalink / raw)
To: Dave Taht; +Cc: cake, cerowrt-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 5170 bytes --]
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@emc.com>
> Date: Tue, Jul 7, 2015 at 8:10 PM
> Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs?
> To: "tsvwg@ietf.org" <tsvwg@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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
--
Mikael Abrahamsson email: swmike@swm.pp.se
^ permalink raw reply [flat|nested] 2+ messages in thread