Re: [rtcweb] [tsvwg] Diffserv QoS for Video

["Black, David" <[e-mail]>]

> 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

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Tuesday, May 10, 2016 4:19 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [tsvwg] Diffserv QoS for Video
> 
> 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:[e-mail]]
> Gesendet: Dienstag, 10. Mai 2016 09:36
> An: Geib, Rüdiger; [e-mail]
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [tsvwg] Diffserv QoS for Video
> 
> 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
> 
> 
> Den 10. mai 2016 08:56, skrev [e-mail]:
> > 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:[e-mail]]
> > Gesendet: Montag, 9. Mai 2016 21:03
> > An: Geib, Rüdiger
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > Betreff: Re: AW: [tsvwg] Diffserv QoS for Video
> >
> > 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: [e-mail]
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail];
> > [e-mail]
> > 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:
> >>
> >> 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
> >>
> >