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

["Lee, Richard FTC" <[e-mail]>]

I think peer to peer communications are fine and will work akin to the Skype (Best Effort delivery) model
Session quality will suffer periodically. While annoying, part of the price to pay for a free service
The expectation of providing network guarantees for timely service delivery does require active intervention (ToS or DSCP) with associated cost
Negotiation of codecs and bandwidth assignments are typically done by the endpoints in a peer to peer endpoints for a given session.
Due to the bandwidth options associated with video, it is expected that controls will be implemented at enterprise borders to enforce session constraints
In part to allow as many sessions as possible.

Enterprise support of webRTC will probably evolve as SIP has done.
There will be a service/proxy exposed to allow communications inside the corporate network
In many organizations protocols that bypass standard firewalls (STUN, TURN, ICE ...) are blocked.

Regards
Rich



From: [e-mail] [mailto:[e-mail]] On Behalf Of Ted Hardie
Sent: Friday, October 11, 2013 1:56 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

On Fri, Oct 11, 2013 at 2:20 AM, <[e-mail]<mailto:[e-mail]>> wrote:
Ted wrote:
> 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?
Here are some examples that were mentioned on the list or elsewhere:
- My company doesn't allow tunnels to the TURN server of some outside WebRTC service. How can I tell the WebRTC service to use my company's TURN server?

I see.  I was taking your original statement "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?" a bit too literally--I thought you were focused purely on prioritization and resource allocation.  If part of what you mean is "how do I discover a service on the local network when I require it", then the answer is going to be dependent on the service, not on the condition that causes you to require it.  That it is, for TURN you look to RFC 5766 and RFC 5928 and their successors, not to RTCWEB.

- My ISP uses DSCP code point x for low delay. How can I tell my WebRTC service to use this code point for the flows that require low delay (as Harald correctly pointed out, only the service self knows about the requirements of a flow)?

So, I'm not sure there are many places where DSCP markings from external parties are trusted at AS borders in any case, but the theory is that we say what DSCP marking should be used and the ISP recognizes it as WebRTC traffic from that code point.  In the case where the ISP does trust external markings but doesn't use a standard one, you have a bit of problem in any case--the marking on the packet from the peer may be valid in the origin network, so recommending it be changed to the one in the destination may result in sub-optimal processing in the origin.  At that point, you need one of the two peer networks to adjust the markings at the border.  This is, again, not really a problem for RTCWEB to solve.

- My ISP requires admission control to protect its low delay class from packet loss. How can a WebRTC service contact the resource admission control service (ok, this a bit speculative)?
Yeah, I tend to agree that this is speculative.

In all those cases, the WebRTC service needs information about the user's infrastructure, be it the company intranet or the ISP. We currently don't have a good way to get such information.


For the services like TURN, I believe the answer is "use what ever is defined for that service, rather than inventing a new one for WebRTC".  For the marking, I think the answer has to be "define a standard marking", since you likely can't find the specific markings and then implement translations for all the networks a flow might traverse.
Just my opinion as a contributor, mind, not a chair or company statement.
regards,

Ted



Wolfgang Beck


-----Ursprüngliche Nachricht-----
Von: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] Im Auftrag von Harald Alvestrand
Gesendet: Dienstag, 8. Oktober 2013 13:01
An: [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb