[rtcweb] [avtext] 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:38 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 876DE11E84B6 for <rtcweb@ietfa.amsl.com>; Tue, 22 Oct 2013 07:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.055
X-Spam-Level:
X-Spam-Status: No, score=-1.055 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_20=-0.74, 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 BuF3cUALfr8Y for <rtcweb@ietfa.amsl.com>; Tue, 22 Oct 2013 07:38:00 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7570111E83C8 for <rtcweb@ietf.org>; Tue, 22 Oct 2013 07:37:18 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310221637151652; Tue, 22 Oct 2013 16:37:15 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: 'Harald Alvestrand' <harald@alvestrand.no>, rtcweb@ietf.org, 'Magnus Westerlund' <magnus.westerlund@ericsson.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11667BBA0@xmb-aln-x02.cisco.com> <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no>
In-Reply-To: <5253E5EB.8030608@alvestrand.no>
Date: Tue, 22 Oct 2013 16:37:18 +0200
Message-ID: <02bf01cecf34$35e174a0$a1a45de0$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C0_01CECF44.F96A44A0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7EFbkmQFwvQDChQl+1C3afCRd/RgE7zuMw
Content-Language: sv
Cc: 'Colin Perkins' <csp@csperkins.org>
Subject: [rtcweb] [avtext] 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:38:22 -0000
Harald, I mostly agree with the quality requirements of different real-time traffic that the WebRTC browser/application may use. But rather than asking the application, let's convey the bandwidth and priority requirements to the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by the network, like diffserv bits are). Such marking must also be available for incoming traffic, which is especially important in RSVP type of networks, that has to reserve bandwidth for it. There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which arent sufficient anyway). Let's use the RTP header extension field that also is visible outside the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to encode it though. Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other webrtc usages of the RTP header extension in 5.2 (there can be many header extensions according to RFC 5285) and in 9 there is "WebRTC Use of RTP: Future Extensions". So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. Such marking is done in every RTP packet so it can be set individually for each stream and could even be changed during a session (e.g. when limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. I suggest that two parameters (e.g. two bytes each) are encoded into the RTP header extension: A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence on a logarithmic scale. B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream. And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits. Please note the totally different requirements a diffserv and an RSVP network have to know, so lets put all into these bytes. (E.g. a diffserv network don't need the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) /Karl PS Microsoft seems to have done work in this field, defining a proprietary attribute MS Service Quality; However that seems to apply to the TURN server allocation request and would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. This is 2.2.2.19 MS-Service Quality Attribute from http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource allocation, bandwidth prioritization, and data delivery methods. If the attribute is not present in the Allocate request message, the TURN server SHOULD assume that the data stream is audio with best effort delivery. The format of this attribute is as follows... ... The following stream types are supported in this extension. All other stream types are reserved for future use. § "0x0001": Audio § "0x0002": Video § "0x0003": Supplemental Video § "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. All other service quality levels are reserved for future use. § "0x0000": Best effort delivery. § "0x0001": Reliable delivery. -----Ursprungligt meddelande----- Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org Ämne: 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 dont 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 <mailto:rtcweb@ietf.org> rtcweb@ietf.org <https://www.ietf.org/mailman/listinfo/rtcweb> 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