[rtcweb] Diffserv QoS for Video - summary

"Black, David" <david.black@emc.com> Sat, 07 May 2016 01:13 UTC

Return-Path: <david.black@emc.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DCC3912D0AE; Fri, 6 May 2016 18:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.317
X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tga4pdJJ1KlF; Fri, 6 May 2016 18:13:49 -0700 (PDT)
Received: from mailuogwdur.emc.com (mailuogwdur.emc.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB17812B014; Fri, 6 May 2016 18:13:48 -0700 (PDT)
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com []) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u471DkBn024318 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 May 2016 21:13:47 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u471DkBn024318
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1462583627; bh=kBVxpHyXiNlH0R3f6sfsICm1gUM=; h=From:To:CC:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PPERISL2ROAYHVat3Aiod3fJ8lpR6IhpJ/O48MIhnbqsZFdNWGmvrovvFE0Pbb65E 0OAeQ+n31ba1+be3UI06h0+SfiIooHr/iXOv2MZGyGFSqHrb0VNeYx832RClNyPfWj 29e+TK8R1vHmggYDflK/cJNI5mbV7Pi6kgYeX8EQ=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u471DkBn024318
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com []) by maildlpprd53.lss.emc.com (RSA Interceptor); Fri, 6 May 2016 21:13:23 -0400
Received: from MXHUB220.corp.emc.com (MXHUB220.corp.emc.com []) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u471DU0F014832 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 6 May 2016 21:13:30 -0400
Received: from MX104CL02.corp.emc.com ([]) by MXHUB220.corp.emc.com ([]) with mapi id 14.03.0266.001; Fri, 6 May 2016 21:13:30 -0400
From: "Black, David" <david.black@emc.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Diffserv QoS for Video - summary
Thread-Index: AdGn/aTXCbReDyBzSX2UbV32jIffJg==
Date: Sat, 07 May 2016 01:13:29 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362E99ADF8@MX104CL02.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/u5laVTtDlVHnWodxYqt9qB7wa2I>
Cc: "Black, David" <david.black@emc.com>
Subject: [rtcweb] Diffserv QoS for Video - summary
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 May 2016 01:13:51 -0000

Many thanks for the productive comments - I'm replying to my own message in an attempt to summarize the discussion and what ought to be done to the drafts as a result.

-- [A] Brian Carpenter asked: what is the definition of "interactive"?

Paul Jones answered: from RFC 4594, which comes from G.1010.

IMHO, both drafts should cite RFC 4594 and G.1010 for this discussion and definition.

-- [B] Brian Carpenter asked about whether the WebRTC API supports a parameter to distinguish interactive video from non-interactive video.

The definitive answer from a number of sources (e.g., Stefan HÃ¥kansson) is "No."   There is additional text in the tsvwg-rtcweb-qos draft that will need to be revised to align with this answer (e.g., for WebRTC, there is no input to the browser to distinguish interactive vs. non-interactive video and the browser SHOULD NOT try to do so on its own).

-- [C] Bernard Aboba wondered  whether a "non-interactive" marking/priority would deliver anything useful to application developers independent of whether or not it's supported in the WebRTC API..

My perception is that the answer here is "Yes" which leads to leaving the Non-Interactive Video flow type in the tsvwg-rtcweb-qos draft, but making it clear that use of Web RTC via the browser API currently does not (and cannot) use that flow type.

-- [D] Finally, Brian Carpenter asked about non-interactive audio:

  Finally, why is audio not also subdivided into interactive and
  non-interactive? As far as I can see, both are logically possible.

I believe the answer is a lack of interest combined with absence of support in WebRTC "running code".

Further comments?

Absent further discussion, I'll work offline with the draft authors on text changes for both drafts in accordance with this summary.

Thanks, --David

> -----Original Message-----
> From: Black, David
> Sent: Wednesday, May 04, 2016 11:26 AM
> To: tsvwg@ietf.org; rtcweb@ietf.org
> Cc: Black, David
> Subject: Diffserv QoS for Video
> Greetings,
> I write as the shepherd for the WebRTC QoS draft (draft-ietf-tsvwg-rtcweb-qos).
> IETF Last Call on this draft uncovered an issue that appears to also require
> changes in the Web RTC transports draft (draft-ietf-rtcweb-transports).
> The Web RTC draft  specifies different Diffserv Codepoints (DSCPs) for use with
> Interactive vs. Non-Interactive Video (with or without audio in both cases):
> https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5
> The IETF LC issue is: How does an implementer determine whether video is
> interactive vs. non-interactive?
> The answer (unexpected to at least me) is that this can't be done for current
> WebRTC - all video has to be treated as interactive because there's no API
> support to distinguish interactive video from non-interactive video.  That
> doesn't appear to be stated anywhere obvious, and a TSVWG draft seems
> like the wrong place to do so.
> Hence, this message contains initial proposed changes to both the WebRTC
> Transports draft and WebRTC QoS draft to resolve this issue without removing
> any of the DSCPs currently specified for video in the WebRTC QoS draft.
> We should resolve this within the next few days, as the WebRTC QoS draft is
> (finally!) on the IESG telechat agenda for May 19.
> --- WebRTC Transports draft - proposed changes
> In Section 4 Media Prioritization, after the following existing text:
>    For media, a "media flow", which can be an "audio flow" or a "video
>    flow", is what [RFC7656] calls a "media source", which results in a
>    "source RTP stream" and one or more "redundancy RTP streams".  This
>    specification does not describe prioritization between the RTP
>    streams that come from a single "media source".
> Add a new paragraph:
>    All media flows in WebRTC are assumed to be interactive; there is
>    no browser API support for non-interactive media, aside from sending
>    non-interactive media content via the data channel.
> This ought to cite a W3C reference for the WebRTC API - the following
> appears plausible:
>    [W3C.WD-webrtc-20120209]
>               Bergkvist, A., Burnett, D., Jennings, C., and A.
>               Narayanan, "WebRTC 1.0: Real-time Communication Between
>               Browsers", World Wide Web Consortium WD WD-webrtc-
>               20120209, February 2012,
>               <http://www.w3.org/TR/2012/WD-webrtc-20120209>.
> -- WebRTC QoS draft - proposed changes
> In Section 5 DSCP Mappings, after the following existing text:
>    The browser SHOULD first select the flow type of the flow.  Within
>    the flow type, the relative importance of the flow SHOULD be used to
>    select the appropriate DSCP value.
> Add a new paragraph:
>    The current WebRTC browser API does not support non-interactive
>    video; all video is assumed to be interactive [I-D.ietf-rtcweb-transports].
>    Browsers MUST NOT use the DSCP mappings for Non-Interactive Video
>    in Table 1.  Non-browser implementations of WebRTC MAY use the
>    DSCP mappings for Non-Interactive Video in Table 1 for video that is
>    known to not be interactive, e.g., all video in a video playback application
>    based on a custom implementation of the WebRTC protocols would not
>    be interactive.
> ------
> Comments are welcome - as noted, above,  we should resolve this in
> the next few days in order to avoid pulling the WebRTC QoS draft off
> of the May 19 IESG telechat agenda. Please reply to both the TSVWG and
> RTCWEB lists, as we need  a coherent solution across both drafts.
> I want to thank Colin Perkins for suggesting the video playback example.
> Thanks, --David (as WebRTC QoS draft shepherd)