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

["Karl Stahl" <[e-mail]>]

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

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. 

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?

> IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field.

Sure, but current OS stop those bits to be set by the WebRTC browser. And
when multiplexing everything over one UDP port, I doubt we will ever see
diffserv bits coming from the application. Further, diffserv bits does not
give us the bandwidth required for RSVP networks.

In cable networks today, they look into the SIP/SDP signaling to see the
bandwidth to reserve (usually only G.711 I believe). That cannot be done
with no signaling WebRTC and all encrypted. On another track, I suggested
enforcing TURN to be used (by eating the initial STUN packet). That could
capture the ICE initiated media flow, but there is still a need to estimate
the bandwidth requirement for RSVP type of networks.

/Karl


-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[e-mail]] 
Skickat: den 7 oktober 2013 10:38
Till: Karl Stahl
Kopia: [e-mail];
[e-mail]
Ämne: Payload Types assignments was Re: SV: [rtcweb] [mmusic] WGLC of
draft-ietf-rtcweb-use-cases-and-requirements-11

Hi Karl,

On 2013-10-03 00:50, Karl Stahl wrote:
> Hej Magnus,
> 
> Hmm, if we (IETF) allowed ourselves to each decennium allocate payload 
> types for the 3-4 most common/important codecs, the unassigned pool 
> (PT:35-71) would last 100 years! I think our own Opus, H.264, and 
> maybe some mobile and the Skype codec (SILK) could be honored AND of 
> course the mandatory video codec that will be selected for WebRTC (VPx or
H.26y).

Yes, but we already today have at least 126 media type names registered that
has RTP Payload formats. Out of these a significant number do requires
additional parameters, like H.264, AMR, i.e. one media type may not
represent one interoperability point but many.

Thus static assignment of codec plus parameters are totally out of the
question. We also have various different usages and none includes all the
available media types, if they would, we already now would have run out of
RTP payload types.

> 
> The need for assigning new payload types may have been small - dynamic 
> payload types works equally well - EXCEPT for the quality routing reason.
> (RSVP quality type of networks could at least know maximum bandwidth. 
> DPI guesswork could/should be avoided.) So with WebRTC, expecting to 
> finally bring us beyond POTS quality on a massive scale - we (IETF) 
> may reconsider...

IETF already have define an IP field for quality based routing and
forwarding: The DiffServ Code Point field. If you argument is that it is
difficult to agree on mapping between media types and quality to static
value being used everywhere, the same applies to RTP level. You will not be
able to make legacy abide any static assignments. So you will see voice in
the video class etc and vice versa.

> 
> If that really is impossible, is there anything stopping _the RTCWEB 
> RFC_ to recommend (MUST or SHOULD) specific _dynamic_ payload types to 
> be used for e.g. Opus:PT=111, H.264:PT=112, VP9:PT=113 etc.? That may 
> be good enough, and surely others, like SIP-client, would follow this 
> usage (or add it to their recommendations).

What would you gain if you can't rely on the PT value being used for the
defined usage. In general you will see other IP/UDP/RTP flows with
PT=111 that will be H.264, or MPEG-2 or what ever.

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. What layer do you want to achieve them at. Who are going to
react to you information and how can one trust it across administrative
boundaries. Also what scope for this information are you trying to achieve,
full end to end, only first two hops?

This is a difficult issue with no good solutions. A restricted problem may
be possible to solve, a larger one may not be realistic.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------