From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6765121F9E3; Sat, 18 Jul 2015 01:41:25 -0700 (PDT) Received: by oigd21 with SMTP id d21so41178607oig.1; Sat, 18 Jul 2015 01:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=4wRe4PChDQSvw2RmlSWI9PmlXwvBQzzYyxN4SzNmdDg=; b=yYOOYdZ3AP7gI4GA/atNWEHQJdwWvKcxeyY4AqseD0pL4g0BUQrAUcWh7KEcEGBznx 8/b1MY42SRN39LRp1QloqOkgTZYI0x+LNjrwqfN98P2aAMtuZd5ZyU5pS52XWjHc1VFE IYz3dBkERocnwmdq8DmH2TosTQTMDlpWSFTYi0bxIjkujc0LhQVPOebjFUEysP30lWWC 6KS0JOrT9Qb8QVAYO/SkxMGpu87d1GTHudqKiMAhJtCIMllRgJfaSygwZ9QsWei27dE5 mXXl1RTiuC/pktrrDBKkyfYtOixxD3m0gf63GFqZ9uOewUB3xhZUvlyWC0bcUKLBqjfB UnZg== MIME-Version: 1.0 X-Received: by 10.60.78.230 with SMTP id e6mr17906872oex.24.1437208883998; Sat, 18 Jul 2015 01:41:23 -0700 (PDT) Received: by 10.202.107.9 with HTTP; Sat, 18 Jul 2015 01:41:23 -0700 (PDT) In-Reply-To: References: Date: Sat, 18 Jul 2015 10:41:23 +0200 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [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 08:41:53 -0000 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#secti= on-6 Something is definitely wrong here, as the DART draft clearly advis= es 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-cha= nnel 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 ---------------------------------------------------- --=20 Dave T=C3=A4ht 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