From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0EDED21F9F0; Sat, 18 Jul 2015 04:41:21 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 977F7A2; Sat, 18 Jul 2015 13:41:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1437219677; bh=E2VrTIXJ79Eb6zewNTNRLVHBwZ0GmRN/hAXBl9y0RKs=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=a9xIMo10kmHFY/DL7sYnx/sUWq4Qi87ZmmsMXLCz4tK7GunkwFERXg8S1KbbKVSZP iRvyzbCog6euUH3DKKRFf4+91aYIR5HoXAhVo5mtVkaNAfe8DskJ5hZume4eGZUcn0 0KgqMvzWNmMkqi/UIWUoEabVd7Kzv2idwWj2QzM4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8FF899F; Sat, 18 Jul 2015 13:41:17 +0200 (CEST) Date: Sat, 18 Jul 2015 13:41:17 +0200 (CEST) From: Mikael Abrahamsson To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-137064504-1996584055-1437219677=:11810" Cc: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Fwd: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 11:41:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1996584055-1437219677=:11810 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT 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 > Date: Tue, Jul 7, 2015 at 8:10 PM > Subject: [tsvwg] draft-ietf-tsvwg-rtcweb-qos-04: How many DSCPs? > To: "tsvwg@ietf.org" > > > > > 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. > > > > 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 ---137064504-1996584055-1437219677=:11810--