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

[<[e-mail]>]

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:[e-mail]] 
Gesendet: Donnerstag, 12. Mai 2016 22:21
An: Black, David; Geib, Rüdiger; [e-mail]
Cc: [e-mail]; [e-mail]
Betreff: Re: [tsvwg] Diffserv QoS for Video

> 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

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
> 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
>>>>
>>>