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

[Ted Hardie <[e-mail]>]

On Thu, Oct 10, 2013 at 8:02 AM, <[e-mail]> wrote:

> The basic question seems to be: how can the web server or JS client learn
> about local policy enforcement elements in the user's network and access
> them to allocate bandwidth, setup priorisation etc?
>
>
So, I'm a little confused about why that is the basic question.  If the
prioritization is done by something like a diffserv code point, it seems
like the question is how the flow signals its classification, rather than
to whom it signals that .  I would presume that the networks which honor
such markings would be constructed such that some conversant network
element is on path.  What it is and where it is kind of aren't the JS app
or browser's issue.

What am I missing?

Ted



> The ALTO WG had a very similar problem and proposed DHCP after DNS experts
> dismissed a discovery mechanism based on reverse DNS lookups.
>
> The classical solution: avoid the problem by having a webrtc server in
> your local network which does policy enforcement/QoS priorisation etc, and
> interconnects to some other webrtc server with a standardized protocol like
> SIP or XMPP. Popular in RTCWEB, less popular elsewhere..
>
> The DHCP way: let the browser learn about the policy enforcement elements
> through DHCP, it may communicate them to the server. This has some
> problems. There are no widely adopted DHCP APIs, and the policy enforcement
> elements may be unwilling to let some random web server access them.
>
> DNS magic: derive the address of your local policy enforcement element by
> manipulating the result of a reverse DNS lookup of the global IP address.
>
> Manual configuration: Solves only the problem of missing DHCP APIs and
> introduces the usability nightmare we know too well from SIP clients.
>
> 3rd party auth: the user authenticates with a local idP, which not only
> carries the user's name but also the local policy enforcement urls as
> attributes. A web server can use the 3rd party auth token to access the
> local network elements. Haven't thought this through yet.
>
>
> Wolfgang Beck
>
> -----Ursprüngliche Nachricht-----
> Von: [e-mail] [mailto:[e-mail]] Im Auftrag
> von Harald Alvestrand
> Gesendet: Dienstag, 8. Oktober 2013 13:01
> An: [e-mail]
> Betreff: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC
> of draft-ietf-rtcweb-use-cases-and-requirements-11
>
> 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.
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>