Subject: [rtcweb] Diffserv QoS for Video

From: "Black, David" <[email-masked]>
Date: Wed, 4 May 2016 15:26:11 +0000

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)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 May 2016 08:28:28 +1200

I fear I have an up-level question: what is the definition of "interactive"?

draft-ietf-tsvwg-rtcweb-qos doesn't define it, presumably because it was
assumed to be obvious, but thinking about David's suggestions, I decided
that it isn't so obvious.

https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4 says:

   The following are the inputs provided by the WebRTC application to
   the browser:

   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.

Firstly, I'm puzzled by the apparent contradiction between the first
sentence (in which the app provides input to the browser) and the second
sentence (in which to the browser provides input to something else).

Then, is it clear how the browser "knows" this? If David's statement below
about the API is correct, the browser actually cannot "provide this input"
as stated in the above quotation. Or I am confused.

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

Regards
   Brian

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 May 2016 16:01:41 -0700

Brian Carpenter said:

"Then, is it clear how the browser "knows" this?"

[BA] The application explicitly provides information to the browser by
setting the RTCRtpEncodingParameters.priority attribute via the
sender.setParameters() API:

dictionary RTCRtpEncodingParameters {             unsigned long
ssrc <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>;
            RTCRtpRtxParameters rtx
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>;
          RTCRtpFecParameters fec
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-fec>;
          boolean             active
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-active>;
            RTCPriorityType     priority
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-priority>;
            unsigned long       maxBitrate
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>;
            unsigned long       maxFramerate
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>;
            DOMString           rid
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rid>;
          double              scaleResolutionDownBy
<http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy>
= 1.0;
};

The Priority and QoS Model is described in the latest WebRTC 1.0 Editor's
draft (http://w3c.github.io/webrtc-pc/) Section 4.10:

4.10 Priority and QoS Model

Many applications have multiple media flows of the same data type and often
some of the flows are more important than others. WebRTC uses the priority
and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [
TSVWG-RTCWEB-QOS] to provide priority and DSCP marking for packets that
will help provide QoS in some networking environments. The priority setting
can be used to indicate the relative priority of various flows. The
priority API allows the JavaScript applications to tell the browser whether
a particular media flow is high, medium, low or of very low importance to
the application by setting the priorityproperty of
RTCRtpEncodingParameters objects
to one of the following values.
4.10.1 RTCPriorityType Enum

enum RTCPriorityType {
    "very-low <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-low>",
    "low <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.low>",
    "medium <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>",
    "high <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.high>"
};

On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 May 2016 12:36:58 +1200

Thanks Bernard.

All the same, I think the phrasing I quoted at
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4
is problematic; it implies that there's a Boolean property "interactive"
which clearly is not supported in the encoding parameters.

Regards
   Brian

On 05/05/2016 11:01, Bernard Aboba wrote:
> [BA] The application explicitly provides information to the browser by setting the RTCRtpEncodingParameters.priority attribute
> via the sender.setParameters() API: 
> 
> dictionary RTCRtpEncodingParameters { unsigned long ssrc <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>;
> |RTCRtpRtxParameters| rtx <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>; |RTCRtpFecParameters| fec
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-fec>; boolean active
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-active>; |RTCPriorityType| priority
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-priority>; unsigned long maxBitrate
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>; unsigned long maxFramerate
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>; DOMString rid
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rid>; double scaleResolutionDownBy
> <http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy> = 1.0; };
> 
> 
> The Priority and QoS Model is described in the latest WebRTC 1.0 Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10: 
> 
> Many applications have multiple media flows of the same data type and often some of the flows are more important than others.
> WebRTC uses the priority and Quality of Service (QoS) framework described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to
> provide priority and DSCP marking for packets that will help provide QoS in some networking environments. The priority setting
> can be used to indicate the relative priority of various flows. The priority API allows the JavaScript applications to tell the
> browser whether a particular media flow is high, medium, low or of very low importance to the application by setting
> the |priority|property of ||RTCRtpEncodingParameters|| objects to one of the following values.
> 
> 
> On Wed, May 4, 2016 at 1:28 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 May 2016 18:41:10 -0700

Brian said:

"All the same, I think the phrasing I quoted at
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-4
is problematic; it implies that there's a Boolean property "interactive"
which clearly is not supported in the encoding parameters."

[BA] Overall, I'm not clear that this thread is asking the right questions,
or making correct statements about the existing API.  To my mind, the real
question is whether a "non-interactive" marking/priority would deliver
anything useful to application developers, not whether the API could
support it.

The encoding parameters can be used to allow an application to specify a
priority attribute.  If a "non-interactive" marking and associated priority
attribute were to be defined, the current API could allow applications to
specify that.  So citing a 4-year old version of the WebRTC 1.0
specification as justification for the lack of API functionality doesn't
make sense to me.   Since the browser just does what it is told to do by
the application, whether the browser "knows" whether the media is
interactive or not also does not matter.

The real question is whether a  "non-interactive" marking/priority setting
would be useful to application developers.

Uni-directional communications (e.g. "sendonly", "recvonly") is supported
within WebRTC.  Would those kind of flows benefit from a "non-interactive"
marking? In most cases, I suspect that in general it would not be useful (a
possible exception might be use of SVC codecs protecting only the base
layer with FEC/RTX).

It is conceivable that an application might want to attach a track to a
sender that isn't obtained from getUserMedia() (see:
http://w3c.github.io/mediacapture-main/) or getDisplayMedia() (see
https://w3c.github.io/mediacapture-screen-share/).  Again, the question is
whether a "non-interactive" marking/priority would be helpful in those
cases.  I suspect the answer to that is also "no" for similar reasons.

On Wed, May 4, 2016 at 5:36 PM, Brian E Carpenter <
[email-masked]> wrote:

> setting the RTCRtpEncodingParameters.priority attribute
> > dictionary RTCRtpEncodingParameters { unsigned long ssrc <
> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-ssrc>;
> > |RTCRtpRtxParameters| rtx <
> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-rtx>;
> |RTCRtpFecParameters| fec
> |RTCPriorityType| priority
> > <
> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxBitrate>;
> > <
> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-maxFramerate>;
> DOMString rid
> > <
> http://w3c.github.io/webrtc-pc/#widl-RTCRtpEncodingParameters-scaleResolutionDownBy>
> = 1.0; };
> >
> >
> > The Priority and QoS Model is described in the latest WebRTC 1.0
> Editor's draft (http://w3c.github.io/webrtc-pc/) Section 4.10:
> >
> > Many applications have multiple media flows of the same data type and
> often some of the flows are more important than others.
> > WebRTC uses the priority and Quality of Service (QoS) framework
> described in [RTCWEB-TRANSPORT] and [TSVWG-RTCWEB-QOS] to
> > provide priority and DSCP marking for packets that will help provide QoS
> in some networking environments. The priority setting
> priority API allows the JavaScript applications to tell the
> > browser whether a particular media flow is high, medium, low or of very
> low importance to the application by setting
> >     "very-low <
> http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.very-low>",
> >     "medium <
> http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.medium>",
> >     "high <http://w3c.github.io/webrtc-pc/#idl-def-RTCPriorityType.high
> >"
> > };
> >
> >
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> says:

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 May 2016 16:30:17 +1200

> To my mind, the real
> anything useful to application developers, 

Absolutely. As I understand things, a media stream in an interactive
session has one requirement that is definitely more stringent than
for a non-interactive session: lower latency. So the question is how
to ensure that the most suitable DSCP is chosen to achieve the required
latency. But that takes us back to
https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-15#section-5
where by some magic the code needs to know the flow type.

This is why trying to compress the subtleties of QoS into a "priority"
parameter is bound to fail. I don't understand how
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-12#section-4.2
is going to work without extending the API.

Regards
   Brian

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 5 May 2016 11:02:33 +0000

> sentence (in which to the browser provides input to something else).

The sentences contradict, but with the API defined the second sentence 
is true.

> as stated in the above quotation. Or I am confused.

There is no browser API to define if the video (or audio) is interactive 
or not, and the reason is that we've dealt only with interactive flows.

I've heard people talk about more robust flows with higher latency for 
situations like lectures and so on, but that is not part of WebRTC 1.0 
(the API standard).

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 05 May 2016 17:47:24 +0000

Brian,

>I fear I have an up-level question: what is the definition of 

That comes from RFC 4594, which comes from G.1010.

>       video with or without audio, or data.

This paragraph has been modified during the course of discussions during 
LC.  The text now reads:

     Flow Type: The application provides this input because it knows
     if the flow is audio, interactive video with or without
     audio, non-interactive video with or without audio, or data.
     For audio that is associated with a video flow, the flow
     type of the associated video MAY be used instead of the
     associated audio type.

>sentence (in which to the browser provides input to something else).

This should have been "application", as it's providing this input to the 
browser, in spite of the fact that the current API does not allow the 
application to indicate interactive or not.

>as stated in the above quotation. Or I am confused.

Yeah, the browser would not know.  At present, it can only assume it's 
interactive based on the fact it is an RTP video and audio flow.

>non-interactive? As far as I can see, both are logically possible.

For WebRTC, audio alone is "interactive" in nature (which is why it's 
marked EF).  However, if one is sending audio and video it makes sense 
to mark them both same way to get the same PHB and hopefully have them 
queued in the same buffers along the path.  Sending audio as EF and 
possibly having a PHB that results in packets arriving much faster than 
corresponding video packets marked as AF42 is not at all helpful for 
applications that have to synchronize the audio and video flows.

I can think of examples of potentially non-interactive video (e.g., 
whiteboard, app sharing, or presentation video).  Likewise, if audio is 
sent with a presentation video it would make sense for the audio to be 
marked similarly to the corresponding video.

Paul

---

From: <[email-masked]>
Date: Mon, 9 May 2016 09:34:25 +0200

Hi Paul,

I've talked with audio/video experts of Deutsche Telekom and they too favored what you recommend below: transport audio and video by the same queue. Your statement below however stops there and the draft text doesn't clarify the issue:

If there's interactive video with audio, then they both should be marked for the same PHB which is:
- EF ?
- AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B frames are to receive a lower priority / 
  higher drop precedence PHB)?

I personally prefer AF4 if audio and video are to be transported in the same queue.

I'd also ask for the draft text to be clear about the issue when to mark audio by the EF PHB. My understanding after reading your statement below is: Audio marked EF if there's no video flow only.

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

[PJ] For WebRTC, audio alone is "interactive" in nature (which is 
  why it's marked EF).  However, if one is sending audio and video 
  it makes sense to mark them both same way to get the same PHB and 
  hopefully have them queued in the same buffers along the path.  
  Sending audio as EF and possibly having a PHB that results in 
  packets arriving much faster than corresponding video packets 
  marked as AF42 is not at all helpful for applications that have 
  to synchronize the audio and video flows.
...

  Paul

Regards, 

Ruediger

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 09 May 2016 19:03:10 +0000

Ruediger,

Perhaps an example might be helpful.  How about I add this text for 
illustrative purposes?

     To illustrate the use of the above table, let us assume the
     application assigns a priority of "medium" to audio and video
     flows.  Given that assumption, if the application wishes to send
     only audio then packets would be marked EF.  However, if the
     application wishes to send both interactive video and audio,
     then audio and video packets would both be marked as AF42 or
     AF43.  The intent is to ensure that when both audio and video
     are being sent together that they receive similar per-hop
     behavior.

This doesn't get into the preference for AF42 vs. AF43. If it were me, 
I'd mark all audio as AF42 and only key video frames as AF42.  All 
predictive frames would be sent with an AF43 marking.  I might even take 
it a step further and classify all audio as "high".  However, I've seen 
a tremendous amount of debate on this before, so I'd prefer to not go 
too far in dictating audio markings vs. video.  I do think most people 
generally agree about at least ensuring the class is the same, otherwise 
the wildly different PHB introduces skew between A/V packet arrival, 
thus inflating the size of buffers managing the A/V streams.  However, 
we do not want to dictate that audio should be treated significantly 
better than audio.  For deaf users, for example, the audio really isn't 
important at all.  That is perhaps an extreme example, but it 
nonetheless highlights why we should be cautious about exactly what we 
normatively mandate.

Paul

------ Original Message ------
From: [email-masked]
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Sent: 5/9/2016 3:34:25 AM
Subject: AW: [tsvwg] Diffserv QoS for Video

>Hi Paul,
>
>I've talked with audio/video experts of Deutsche Telekom and they too 
>favored what you recommend below: transport audio and video by the same 
>queue. Your statement below however stops there and the draft text 
>doesn't clarify the issue:
>
>I'd also ask for the draft text to be clear about the issue when to 
>mark audio by the EF PHB. My understanding after reading your statement 
>below is: Audio marked EF if there's no video flow only.
>
>...

---

From: <[email-masked]>
Date: Tue, 10 May 2016 08:56:55 +0200

Hi Paul,

I think we agree, that audio and video frames, if both are part of the same (interactive) media flow should be transported by the same PHB [PJ] or the same queue [RG]. The latter is ensured, if the same PHB is picked for audio and video. To me the text of the draft so far doesn't express that both audio and video are supposed to use an "Interactive Video..." PHB, if both are present. I'd prefer to have text with a non binding standard requirement saying  

     However, if the application wishes to send both interactive 
     video and audio, it is RECOMMENDED to transport audio 
     and video packets by the same per hop behavior. For example, 
     audio and video packets would both be marked as AF42 or
     AF43. 

I don't insist on descriptive text proposing to transport audio by an AF4 PHB offering a lower drop ratio than that used to transport video. My audio/video experts support this and I'm pretty sure, that also Cisco representatives mentioned that audio quality ranks above video quality in telepresence sessions.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [mailto:[email-masked]] 
Gesendet: Montag, 9. Mai 2016 21:03
An: Geib, Rüdiger
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: AW: [tsvwg] Diffserv QoS for Video

Ruediger,

Perhaps an example might be helpful.  How about I add this text for illustrative purposes?

This doesn't get into the preference for AF42 vs. AF43. If it were me, I'd mark all audio as AF42 and only key video frames as AF42.  All predictive frames would be sent with an AF43 marking.  I might even take it a step further and classify all audio as "high".  However, I've seen a tremendous amount of debate on this before, so I'd prefer to not go too far in dictating audio markings vs. video.  I do think most people generally agree about at least ensuring the class is the same, otherwise the wildly different PHB introduces skew between A/V packet arrival, thus inflating the size of buffers managing the A/V streams.  However, we do not want to dictate that audio should be treated significantly better than audio.  For deaf users, for example, the audio really isn't important at all.  That is perhaps an extreme example, but it nonetheless highlights why we should be cautious about exactly what we normatively mandate.

Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 May 2016 09:35:42 +0200

FTR: I don't see such an agreement at all.

On the contrary, my perception is that people want the ability to
deliver audio with a lower loss probability and lower delay probability
than video - it's more important to the conversation, and there are
fewer things the recipient can do to hide the losses. If the sender
chose to send them on separate flows, they shold have different DSCP
markings.

I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states,
and I believe that this is what TSVWG has declared consensus on and
wrote in the document that passed WG last call and is currently in
"waiting for writeup" state.

Changing this determination would, at minimum, require reopening the WG
Last Call.
And I'd object.

Harald

---

From: <[email-masked]>
Date: Tue, 10 May 2016 10:18:30 +0200

Hi Harald,

We should avoid to re-open last call. That's not my intent.

I'm working on transport only and my rtcweb input is draft-ietf-tsvwg-rtcweb-qos-15. It states little for audience like me, if the subject is audio and video related to a talking person. I think the relevant statement are lines in a table. I'd appreciate text helping with the interpretation of table. If we can't agree on useful text - leave it as is.

A backbone supporting RTP based TV distribution tends to be engineered for support of an AF4 like QoS class for low loss. I think, telephony codecs, whose RTP streams will be transported by EF, are able to deal with higher packet loss, than multicast based IPTV. 

To me, an audio or telepresence/videoconference call with QoS require admission control. This ensures that they are transported without queuing or drops.

If there's congestion however:

An audio flow marked AF41 should face a lower drop rate than a video flow marked AF42 in the case of congestion at an network edge node. The packets arrive in the same order as they were sent (independent of the flow they belong to).

An EF marked audio flow may experience loss events independent from a video flow marked AF4x. In the case of queuing, one of the flows will be earlier. If both are transported by QoS classes optimized for rtp/udp transport, the difference is a few [ms] per congestion point. If one of the queues is optimized for general data transport, the delay difference is likely to be a double digit [ms] number. The packets of each flow arrive in order as sent, the packets of one flow are delayed against those of the other.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: Harald Alvestrand [mailto:[email-masked]] 
Gesendet: Dienstag, 10. Mai 2016 09:36
An: Geib, Rüdiger; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: [tsvwg] Diffserv QoS for Video

On the contrary, my perception is that people want the ability to deliver audio with a lower loss probability and lower delay probability than video - it's more important to the conversation, and there are fewer things the recipient can do to hide the losses. If the sender chose to send them on separate flows, they shold have different DSCP markings.

I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states, and I believe that this is what TSVWG has declared consensus on and wrote in the document that passed WG last call and is currently in "waiting for writeup" state.

Changing this determination would, at minimum, require reopening the WG Last Call.
And I'd object.

Harald

Den 10. mai 2016 08:56, skrev [email-masked]:
> Hi Paul,
> 
> I think we agree, that audio and video frames, if both are part of the 
> same (interactive) media flow should be transported by the same PHB 
> [PJ] or the same queue [RG]. The latter is ensured, if the same PHB is 
> picked for audio and video. To me the text of the draft so far doesn't 
> express that both audio and video are supposed to use an "Interactive 
> Video..." PHB, if both are present. I'd prefer to have text with a non 
> binding standard requirement saying
> 
>> favored what you recommend below: transport audio and video by the 
>> same queue. Your statement below however stops there and the draft 
>> text doesn't clarify the issue:
>>
>> mark audio by the EF PHB. My understanding after reading your 
>> statement below is: Audio marked EF if there's no video flow only.
>>
>> ...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 May 2016 09:20:04 +0000

I would agree with Harald here. Also, from a UI perspective - in many conferencing situations one would accept momentary losses on the video flow (translated in frozen frames) with the condition that audio is not interrupted. 

Regards,

Dan

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Tuesday, May 10, 2016 10:36 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] [tsvwg] Diffserv QoS for Video

Harald

_______________________________________________
rtcweb mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtcweb&d=CwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=LRCjhQ0yEedzRLgaUmB1PfpGWcJs-rcwLGlF1JwmCUU&s=S1c9zdgPuaM4cdNYgbcC4N1r1V2E4MiFSswi1EEmmTE&e=

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 11 May 2016 03:31:34 +0000

Yeah, that's a good point.   Let's not go down the path of re-opening a 
new round of changes that would require yet another LC and more time.

Paul

------ Original Message ------
From: "Harald Alvestrand" <[email-masked]>
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Sent: 5/10/2016 3:35:42 AM
Subject: Re: [tsvwg] Diffserv QoS for Video

>>  I think we agree, that audio and video frames, if both are part of 
>>the same (interactive) media flow should be transported by the same 
>>PHB [PJ] or the same queue [RG]. The latter is ensured, if the same 
>>PHB is picked for audio and video. To me the text of the draft so far 
>>doesn't express that both audio and video are supposed to use an 
>>"Interactive Video..." PHB, if both are present. I'd prefer to have 
>>text with a non binding standard requirement saying
>>
>>  I don't insist on descriptive text proposing to transport audio by an 
>>AF4 PHB offering a lower drop ratio than that used to transport video. 
>>My audio/video experts support this and I'm pretty sure, that also 
>>Cisco representatives mentioned that audio quality ranks above video 
>>quality in telepresence sessions.
>>
>>  Regards,
>>
>>  Ruediger
>>
>>
>>  This doesn't get into the preference for AF42 vs. AF43. If it were 
>>me, I'd mark all audio as AF42 and only key video frames as AF42.  All 
>>predictive frames would be sent with an AF43 marking.  I might even 
>>take it a step further and classify all audio as "high".  However, 
>>I've seen a tremendous amount of debate on this before, so I'd prefer 
>>to not go too far in dictating audio markings vs. video.  I do think 
>>most people generally agree about at least ensuring the class is the 
>>same, otherwise the wildly different PHB introduces skew between A/V 
>>packet arrival, thus inflating the size of buffers managing the A/V 
>>streams.  However, we do not want to dictate that audio should be 
>>treated significantly better than audio.  For deaf users, for example, 
>>the audio really isn't important at all.  That is perhaps an extreme 
>>example, but it nonetheless highlights why we should be cautious about 
>>exactly what we normatively mandate.
>>
>>  Paul
>>
>>>same
>>>  - AF4? Like AF41 Audio, AF42 Video (AF43 in addition, if P or B 
>>>frames
>>>  are to receive a lower priority /
>>>  I personally prefer AF4 if audio and video are to be transported in 
>>>the
>>>  same queue.
>>>
>>>statement

---

From: "Black, David" <[email-masked]>
Date: Thu, 12 May 2016 00:19:09 +0000

> I'm working on transport only and my rtcweb input is draft-ietf-tsvwg-rtcweb-
> qos-15. It states little for audience like me, if the subject is audio and video
> related to a talking person. I think the relevant statement are lines in a table. I'd
> appreciate text helping with the interpretation of table. If we can't agree on
> useful text - leave it as is.

As draft shepherd, I think the table text is ok as-is; other WebRTC specs own
the definition of what a media flow is, and one of them would be the appropriate
location for text (if appropriate) to point out that audio for video could be sent
on the same or different or different media flow as the video.   Among the reasons
for this is that deciding whether to use one or two media flows has RTP impacts
that occur well before DSCP assignment to outbound traffic.

Also, in addition to the -16 version of the WebRTC QoS draft that was just uploaded,
I've edited that draft's shepherd writeup to reflect the resolution of the issue around
interactive vs. non-interactive video, including recording the expectation that
there will be some additional text on this topic in the next version of the WebRTC
Transports  draft.

Thanks, --David

> From: tsvwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, May 10, 2016 4:19 AM
> To: [email-masked]
> I'm working on transport only and my rtcweb input is draft-ietf-tsvwg-rtcweb-
> qos-15. It states little for audience like me, if the subject is audio and video
> related to a talking person. I think the relevant statement are lines in a table. I'd
> appreciate text helping with the interpretation of table. If we can't agree on
> useful text - leave it as is.
> 
> A backbone supporting RTP based TV distribution tends to be engineered for
> support of an AF4 like QoS class for low loss. I think, telephony codecs, whose
> RTP streams will be transported by EF, are able to deal with higher packet loss,
> than multicast based IPTV.
> 
> To me, an audio or telepresence/videoconference call with QoS require
> admission control. This ensures that they are transported without queuing or
> drops.
> 
> An audio flow marked AF41 should face a lower drop rate than a video flow
> marked AF42 in the case of congestion at an network edge node. The packets
> arrive in the same order as they were sent (independent of the flow they belong
> to).
> 
> An EF marked audio flow may experience loss events independent from a video
> flow marked AF4x. In the case of queuing, one of the flows will be earlier. If both
> are transported by QoS classes optimized for rtp/udp transport, the difference is
> a few [ms] per congestion point. If one of the queues is optimized for general
> data transport, the delay difference is likely to be a double digit [ms] number.
> The packets of each flow arrive in order as sent, the packets of one flow are
> delayed against those of the other.
> 
> Regards,
> 
> Ruediger
> 
> On the contrary, my perception is that people want the ability to deliver audio
> with a lower loss probability and lower delay probability than video - it's more
> important to the conversation, and there are fewer things the recipient can do to
> hide the losses. If the sender chose to send them on separate flows, they shold
> have different DSCP markings.
> 
> I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 states, and I
> believe that this is what TSVWG has declared consensus on and wrote in the
> document that passed WG last call and is currently in "waiting for writeup" state.
> 
> > I don't insist on descriptive text proposing to transport audio by an AF4 PHB
> offering a lower drop ratio than that used to transport video. My audio/video
> experts support this and I'm pretty sure, that also Cisco representatives
> mentioned that audio quality ranks above video quality in telepresence sessions.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > This doesn't get into the preference for AF42 vs. AF43. If it were me, I'd mark all
> audio as AF42 and only key video frames as AF42.  All predictive frames would be
> sent with an AF43 marking.  I might even take it a step further and classify all
> audio as "high".  However, I've seen a tremendous amount of debate on this
> before, so I'd prefer to not go too far in dictating audio markings vs. video.  I do
> think most people generally agree about at least ensuring the class is the same,
> otherwise the wildly different PHB introduces skew between A/V packet arrival,
> thus inflating the size of buffers managing the A/V streams.  However, we do not
> want to dictate that audio should be treated significantly better than audio.  For
> deaf users, for example, the audio really isn't important at all.  That is perhaps an
> extreme example, but it nonetheless highlights why we should be cautious about
> >> frames are to receive a lower priority /
> >> the same queue.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 May 2016 08:20:47 +1200

> Also, in addition to the -16 version of the WebRTC QoS draft that was just uploaded,

fwiw, as one of the people who's been commenting, I am happy with the changes
that have been made in that version.

Regards
   Brian

---

From: <[email-masked]>
Date: Fri, 13 May 2016 08:47:32 +0200

David,

as I mentioned in an earlier mail, all changes where the WG reached agreement are fine with me and others I don't pursue.

Regards, Ruediger

-----Ursprüngliche Nachricht-----
Von: Brian E Carpenter [mailto:[email-masked]] 
Gesendet: Donnerstag, 12. Mai 2016 22:21
An: Black, David; Geib, Rüdiger; [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: Re: [tsvwg] Diffserv QoS for Video

> Also, in addition to the -16 version of the WebRTC QoS draft that was 

fwiw, as one of the people who's been commenting, I am happy with the changes that have been made in that version.

Regards
   Brian

On 12/05/2016 12:19, Black, David wrote:
>> I'm working on transport only and my rtcweb input is 
>> draft-ietf-tsvwg-rtcweb- qos-15. It states little for audience like 
>> me, if the subject is audio and video related to a talking person. I 
>> think the relevant statement are lines in a table. I'd appreciate 
>> text helping with the interpretation of table. If we can't agree on useful text - leave it as is.
> 
> As draft shepherd, I think the table text is ok as-is; other WebRTC 
> specs own the definition of what a media flow is, and one of them 
> would be the appropriate location for text (if appropriate) to point out that audio for video could be sent
> for this is that deciding whether to use one or two media flows has 
> RTP impacts that occur well before DSCP assignment to outbound traffic.
> 
> Also, in addition to the -16 version of the WebRTC QoS draft that was 
> just uploaded, I've edited that draft's shepherd writeup to reflect 
> the resolution of the issue around interactive vs. non-interactive 
> video, including recording the expectation that there will be some 
> additional text on this topic in the next version of the WebRTC Transports  draft.
> 
> Thanks, --David
> 
>> I'm working on transport only and my rtcweb input is 
>> draft-ietf-tsvwg-rtcweb- qos-15. It states little for audience like 
>> me, if the subject is audio and video related to a talking person. I 
>> think the relevant statement are lines in a table. I'd appreciate 
>> text helping with the interpretation of table. If we can't agree on useful text - leave it as is.
>>
>> A backbone supporting RTP based TV distribution tends to be 
>> engineered for support of an AF4 like QoS class for low loss. I 
>> think, telephony codecs, whose RTP streams will be transported by EF, 
>> are able to deal with higher packet loss, than multicast based IPTV.
>>
>> admission control. This ensures that they are transported without 
>> queuing or drops.
>>
>> An audio flow marked AF41 should face a lower drop rate than a video 
>> flow marked AF42 in the case of congestion at an network edge node. 
>> The packets arrive in the same order as they were sent (independent 
>> of the flow they belong to).
>>
>> An EF marked audio flow may experience loss events independent from a 
>> video flow marked AF4x. In the case of queuing, one of the flows will 
>> be earlier. If both are transported by QoS classes optimized for 
>> rtp/udp transport, the difference is a few [ms] per congestion point. 
>> If one of the queues is optimized for general data transport, the delay difference is likely to be a double digit [ms] number.
>> The packets of each flow arrive in order as sent, the packets of one 
>> flow are delayed against those of the other.
>>
>> Regards,
>>
>> Ruediger
>>
>> deliver audio with a lower loss probability and lower delay 
>> probability than video - it's more important to the conversation, and 
>> there are fewer things the recipient can do to hide the losses. If 
>> the sender chose to send them on separate flows, they shold have different DSCP markings.
>>
>> I believe this is what draft-ietf-tsvwg-rtcweb-qos-15 section 5 
>> states, and I believe that this is what TSVWG has declared consensus 
>> on and wrote in the document that passed WG last call and is currently in "waiting for writeup" state.
>>
>>> PHB is picked for audio and video. To me the text of the draft so 
>>> far doesn't express that both audio and video are supposed to use an 
>> offering a lower drop ratio than that used to transport video. My 
>> audio/video experts support this and I'm pretty sure, that also Cisco 
>> representatives mentioned that audio quality ranks above video quality in telepresence sessions.
>>>
>>> Regards,
>>>
>>> Ruediger
>>>
>>>
>>> illustrative
>> purposes?
>>> me, I'd mark all
>> audio as AF42 and only key video frames as AF42.  All predictive 
>> frames would be sent with an AF43 marking.  I might even take it a 
>> step further and classify all audio as "high".  However, I've seen a 
>> tremendous amount of debate on this before, so I'd prefer to not go 
>> too far in dictating audio markings vs. video.  I do think most 
>> people generally agree about at least ensuring the class is the same, 
>> otherwise the wildly different PHB introduces skew between A/V packet 
>> arrival, thus inflating the size of buffers managing the A/V streams.  
>> However, we do not want to dictate that audio should be treated 
>> significantly better than audio.  For deaf users, for example, the 
>> audio really isn't important at all.  That is perhaps an extreme example, but it nonetheless highlights why we should be cautious about exactly what we normatively mandate.
>>>
>>> Paul
>>>
>>>> I've talked with audio/video experts of Deutsche Telekom and they 
>>>> too favored what you recommend below: transport audio and video by 
>>>> the same queue. Your statement below however stops there and the 
>>>> draft text doesn't clarify the issue:
>>>>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 13 May 2016 15:39:19 +0000

> On May 10, 2016, at 12:56 AM, [email-masked] wrote:
> 
> I think we agree, that audio and video frames, if both are part of the same (interactive) media flow should be transported by the same PHB [PJ] or the same queue [RG]. 

I don't think we have consensus on that in the ART area but my understanding of this spec was that it allowed people that wanted to do that to give them the same and it allowed people that wanted to implement the different queues to do that.