Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

[Harald Alvestrand <[e-mail]>]

On 10/08/2013 09:17 AM, Karl Stahl wrote:
> Hej Magnus,
>
>> Also, are you really interested in knowing that it is VP9 vs H.264, isn't
> the questions this is video of this priority that is important?
>> I think you need to more carefully consider what are the goals you try to
> achieve them.
>
> Actually, my concern is to get an idea of the maximum bandwidth that could
> be required for a WebRTC (ICE) setup media flow. Both voice and video should
> be prioritized over data (their individual priority is of less importance as
> long as there is sufficient bandwidth for both).

You don't know that without knowing what the application is for.
In, for instance, a shooter game with voice backchannels, the movement
and event information (data) is MORE time sensitive than the voice data.

>
> With diffserv you don’t need to know the bandwidth requirement, but with
> RSVP reservation (like in cable and mobile networks) you need to know how
> much to reserve. Voice is like 100's kbit/s, video VP8 or H.264 is like 3,5
> mbps. 

Again, without knowing the application, you don't know that.
The application could decide to use QCIF or HD, and the bandwidth
variation of screencast (semi-static with sudden, large changes) is
completely different from that of a talking head, which is again
completely different from a high-movement scene.

>
> To add to the complication of codec variants, the video codecs in question
> for WebRTC have variable bandwidth, and when there is a poor connection we
> see Chrome reducing the video window size to reduce the bandwidth used... 
>
> I think the payload type field at best can reflect a maximum bandwidth to
> initially reserve bandwidth for, and thereafter make new reservations if the
> bandwidth changes during the call. So could we change RTP to show maximum
> bandwidth instead of payload type in that field outside the encrypted
> payload :) ... Or maybe that is not a joke?

I think these ruminations only lead to one conclusion:

You can't tell what the needed bandwidth is up front without asking the
application.
You can't tell what the right priority ranking is without asking the
application.

If you need to know the bandwidth or the priority up front, the
application has to tell you. Anything else is pure heuristics.