Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
"Karl Stahl" <karl.stahl@intertex.se> Tue, 22 October 2013 14:37 UTC
Return-Path: <karl.stahl@intertex.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C8C11E8494 for <rtcweb@ietfa.amsl.com>; Tue, 22 Oct 2013 07:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.923
X-Spam-Level:
X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_40=-0.185, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tszmSftO3PdF for <rtcweb@ietfa.amsl.com>; Tue, 22 Oct 2013 07:37:29 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7223911E83C7 for <rtcweb@ietf.org>; Tue, 22 Oct 2013 07:36:40 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310221636281499; Tue, 22 Oct 2013 16:36:29 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Dan Wing' <dwing@cisco.com>, 'Ted Hardie' <ted.ietf@gmail.com>, 'Harald Alvestrand' <harald@alvestrand.no>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <524AB730.7040809@ericsson.com> <525272E8.5050300@ericsson.com> <5253E5EB.8030608@alvestrand.no> <AAE428925197FE46A5F94ED6643478FEAD1BDC6F0B@HE111644.EMEA1.CDS.T-INTERNAL.COM> <CA+9kkMDo2zu12qLfEeSC2YFaEeK-LbZ4JTDJiG8zfktBb-iB2A@mail.gmail.com> <DEF6A33D-1A61-4F97-9E6B-48399B5FB900@cisco.com>
In-Reply-To: <DEF6A33D-1A61-4F97-9E6B-48399B5FB900@cisco.com>
Date: Tue, 22 Oct 2013 16:36:31 +0200
Message-ID: <02b501cecf34$1a1dc250$4e5946f0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B6_01CECF44.DDA69250"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7G4vcMd4grRwnSQw68FakoPtGiLAIMBzEQ
Content-Language: sv
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2013 14:37:35 -0000
This discussion got side tracked from where I started it from, so in the next two mails I am jumping back to the threads where the original subjects were left. Comment on this discussion: Using a WebRTC browser as a client into an application specific network (e.g. IMS/VoLTE/RCS) is one usage of WebRTC. When building such a gateway as a Web application, doesnt the gateway (the web application) in itself know the characteristics of the application specific network? I dont see the need to discover that. But such gateway has the other side towards the Internet - That is where we have the Web and the WebRTC browser. For the Internet side (in general, and of course with browser to browser communication over the Internet also in mind) I raised two questions: 1) How can the browser find a network provided TURN server (both local on a LAN or provided by a carrier)? 2) Can the WebRTC browser/application convey real-time quality requirements to the network, by using the payload type (that is what we can still see in RTP, when both the payload and signaling are hidden from the network as it is with WebRTC, and diffserv bits are not sufficient and not available through the OSs). These questions are related: There are carriers wanting to support WebRTC traffic with better Internet access than their data crowded best effort accesses. ICE/STUN/TURN allows a network provider to capture the real-time traffic in a TURN server, where the network provider can offer a better path for real-time traffic. Capturing such TURN flow, is a good start for providing better network quality, but it would be even better would if the bandwidth requirements and maybe some more qualities could be seen by the TURN server, e.g. by signaling them in the RTP payload type. (This is especially true and I would say required for RSVP type of networks, that has to reserve bandwidth.) Jumping back to the two threads I started which were left at: 1) Justin pointing out the bootstrap problem of using reverse DNS to find a network provided TURN server. (How is the STUN server to use first found?) I will instead propose an anycast-way, that I think will do everything we are looking for. 2) Harald listing the media types and their various quality needs. There is actually a good way to signal those needs to the network (without using the PT, or diffserv bits, which arent sufficient for RSVP type of networks anyway). The RTP header extension field is also visible to the network, and a week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the use of the extension field for classification of the traffic. /Karl Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Dan Wing Skickat: den 12 oktober 2013 02:35 Till: Ted Hardie Kopia: rtcweb@ietf.org Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 On Oct 10, 2013, at 9:30 AM, Ted Hardie <ted.ietf@gmail.com> wrote: On Thu, Oct 10, 2013 at 8:02 AM, <BeckW@telekom.de> 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? * Several operating systems do not allow non-privileged applications to set DSCP bits at all; Windows, for example. Yes, I know everyone is supposed to use any other OS, but Linux has also only allowed certain DSCP values to be set. * When joining a network, the DSCP values for the network cannot be learned or discovered -- we lack a protocol to do that. The RFCs that define DSCP values are not standards (they are informational) and many a network choose their own values. * Setting the correct DSCP value affects only outgoing traffic but has no influence on the incoming traffic. As you stated in a later post, incoming DSCP isn't trusted anyway. "Reflexive DSCP Policy" was attempted years ago to allow the network to assume a host's DSCP settings could be applied to the other direction, but it was rejected I believe during IETF review but I couldn't find record why it was actually disposed (document was draft-ietf-ieprep-reflexive-dscp). -d 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Im Auftrag von Harald Alvestrand Gesendet: Dienstag, 8. Oktober 2013 13:01 An: rtcweb@ietf.org 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 rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Cullen Jennings (fluffy)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Stefan Håkansson LK
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Magnus Westerlund
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Bernard Aboba
- [rtcweb] TURN server address via DHCP, WGLC of dr… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-and-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-use-c… Karl Stahl
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Marc Abrams
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Hutton, Andrew
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Hutton, Andrew
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Sergio Garcia Murillo
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Tirumaleswar Reddy (tireddy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] additional ICE info Bernard Aboba
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] additional ICE info Harald Alvestrand
- Re: [rtcweb] additional ICE info Dan Wing
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Harald Alvestrand
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Markus.Isomaki
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Chenxin (Xin)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] WGLC of draft-ietf-rtcweb-use-cases-… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… cb.list6
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Cullen Jennings (fluffy)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Justin Uberti
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Martin Thomson
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Bernard Aboba
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Jeremy Laurenson (jlaurens)
- [rtcweb] [mmusic] TURN server address via DHCP, W… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Saverio Vardaro
- Re: [rtcweb] additional ICE info Martin Thomson
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Cullen Jennings (fluffy)
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Christer Holmberg
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] [mmusic] TURN server address via DHC… cb.list6
- [rtcweb] Payload Types assignments was Re: SV: [m… Magnus Westerlund
- Re: [rtcweb] TURN server address via DHCP, WGLC o… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Karl Stahl
- Re: [rtcweb] [mmusic] WGLC of draft-ietf-rtcweb-u… Karl Stahl
- Re: [rtcweb] [mmusic] TURN server address via DHC… Justin Uberti
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Harald Alvestrand
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Martin Thomson
- Re: [rtcweb] Payload Types assignments was Re: SV… Ted Hardie
- Re: [rtcweb] Payload Types assignments was Re: SV… Lee, Richard FTC
- Re: [rtcweb] Payload Types assignments was Re: SV… Dan Wing
- Re: [rtcweb] Payload Types assignments was Re: SV… BeckW
- Re: [rtcweb] Payload Types assignments was Re: SV… Karl Stahl
- [rtcweb] [mmusic] Anycast discovery, Was TURN ser… Karl Stahl
- [rtcweb] [avtext] Payload Types assignments was R… Karl Stahl
- [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Magnus Westerlund
- Re: [rtcweb] [tram] Payload Types assignments Charles Eckel (eckelcu)
- Re: [rtcweb] [tram] Payload Types assignments Colin Perkins
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl
- Re: [rtcweb] [tram] Payload Types assignments Harald Alvestrand
- Re: [rtcweb] [tram] Payload Types assignments Karl Stahl