Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard

Magnus Westerlund <> Wed, 23 March 2016 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0ABAD12D6E8; Wed, 23 Mar 2016 03:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SmOlzlBYPVhA; Wed, 23 Mar 2016 03:08:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CB7512D599; Wed, 23 Mar 2016 03:08:09 -0700 (PDT)
X-AuditID: c1b4fb2d-f79c06d000005960-a9-56f26b0716e4
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 13.36.22880.70B62F65; Wed, 23 Mar 2016 11:08:07 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 23 Mar 2016 11:07:16 +0100
Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and other packet markings for WebRTC QoS) to Proposed Standard
References: <>
From: Magnus Westerlund <>
Message-ID: <>
Date: Wed, 23 Mar 2016 11:07:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM2K7ny579qcwg+edyhZ/rtxjsXi2cT6L RUPfXVaLY2/usjmweCxZ8pMpgDGKyyYlNSezLLVI3y6BK2P2wcyCuTIV3yY/Y2tgvC/WxcjJ ISFgInHo5H4mCFtM4sK99WxdjFwcQgKHGSUW9f1ignCWM0osWDqbHcQRFuhmlJhzpgusRURA WOLIo3/sILaQgKPE+kXb2UBsZoFwiSPPJoPZbAIWEjd/NILZvALaEl9WdbKA2CwCqhIH5y0E 6xUViJE4/u4cI0SNoMTJmU/AajgFnCTedS0AsjmAZtpLPNhaBjFeXqJ562xmiLXaEg1NHawT GAVnIemehdAxC0nHAkbmVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBYXtwy2/dHYyrXzse YhTgYFTi4S049zFMiDWxrLgy9xCjBAezkgjvwcxPYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 2T5dDhMSSE8sSc1OTS1ILYLJMnFwSjUwruhUkecIYPz9uGzG9wWFDWrVNmK7vwqa6+e7P+qW vO66WqvJk3HXzrPnvr/62XWw4NIiVrWgleJGKn+e/DxX4M4S9e+wx8IJkdwHZ+Qwb+Zb49Bz g2G2msiUq3qbljWu0Zi58Whs84kDLW2/fZ68KLx2rXTp2ztJRiF7ZsxKXHSpNnatcN6vTCWW 4oxEQy3mouJEALwbVqdXAgAA
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Mar 2016 10:08:17 -0000


Below is the first round on a question, that looks like it needs to be 
addressed, thus I bring it into a public discussion.

Den 2016-03-22 kl. 19:48, skrev Paul E. Jones:
 >> The other comment I have is the following:
>> o Flow Type: The browser provides this input as it knows if the
>>   flow is audio, interactive video with or without audio,
>>   non-interactive video with or without audio, or data.
>> Yes, a browser knows if a MediaStreamTrack's source is a live
>> source, i.e. camera or microphone or a file. Which would indicate
>> the difference between interactive or non. However, I don't
>> understand what the Flow Type description for video contains "with
>> or without audio" as the flow definitions in RTCWEB transport
>> document all indicate flows as containing a single media type. Can
>> you please clarify?
> This relates to the table that follows. The intent is that if a
> WebRTC application is sending audio and video (e.g., a
> videoconference call), then the same DSCP values might be used for
> both the audio and video flows. On the other hand, if only a video
> flow is sent alone (perhaps the audio source is an entirely different
> device), then the browser can still use the same packet marking.

So, I started commenting on this because, the "Flow Types" in the table 
are not really defined. And my interpretation was not that the audio 
could be given the same markings as the Video. I only interpreted it as 
being valid for the video flow. Thus, I think the actual "flow type" 
values in Table 1 needs to be better defined. To my knowledge these 
types are not defined in any other RTCWeb document.

I think what is needed is a definition list for what is meant. I can see 
that pointers for example into RFC 4594 may help making these 
definitions more compact.

One thing that might be a bit tricky is actually the difference between 
interactive and non-interactive (streaming) usages of WebRTC RTP 
streams. It becomes a question if the WebRTC endpoint actually 
accurately can classify these differences. Yes, a live media source, 
like an camera or microphone can on first order be used for 
classification as interactive, while a file source is non-interactive. 
But even the first, can in the application context be non-interactive. 
An example would be an lecturer application. Relaxing the delay from the 
lecturer to the audience is likely fine, especially if one have a "raise 
hand" mechanism and only explicitly invites participants to ask 
questions. To my knowledge there are no API surface to indicate these 
preferences on the MediaStream or MediaStreamTrack level.

I think this document have a potential valuable difference for the 
interactive vs non-interactive, but the rest of the current solution has 
difficulties to utilize this difference. From my perspective I am fine 
with retaining the difference, but the definition must be clear so that 
implementers select the right one. And likely the non-interactive will 
not be much utilized until additional API knobs are created.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: