Re: [rtcweb] [tram] Payload Types assignments

Karl,

what on Earth does TRAM milestone 3 have to do with whatever it is
you're proposing?

TRAM milestone 3 is:

Sep 2014 - Send new proposed standard TURN server discovery mechanism
for enterprises and ISPs to IESG

There's no (zero, nada, none) mention of QoS within that charter.

On 02/26/2014 12:49 AM, Colin Perkins wrote:
> Karl,
>
> I sympathise with your goal, but I really do not think RTP header
> extensions are appropriate for this purpose.
>
> Ignoring the semantic mismatch, in order to identify an RTP header
> extension, you need access to the signalling data, and if you have
> access to the signalling, you can signal the QoS parameters without
> using RTP. 
>
> You state that only the payload is encrypted in SRTP. That is not
> necessarily true. RTP header extensions can be encrypted when RFC 6904
> is in use, and rtcweb-rtp-usage draft recommends this be done in some
> cases. The signalling channel is also likely encrypted end-to-end in
> new applications, so making it difficult to extract the information
> you need to parse the RTP header extension, even if it is unencrypted. 
>
> Besides these focussed issues, I would also urge you to consider the
> much broader comments Magnus made. The QoS problem is broad, and a
> point solution based on RTP header extensions - even if it were
> workable, which I doubt - would address only a small part of the
> problem space.
>
> Colin
>
>
>
>
> On 25 Feb 2014, at 01:45, Karl Stahl <karl.stahl@intertex.se
> <mailto:karl.stahl@intertex.se>> wrote:
>>
>> Colin,
>>
>>  
>>
>> If the below were the case, it would be “DPI guesswork” that I also
>> advice against. RTP doesn’t even have unique protocol header within
>> UDP – it can even be confused with other UDP payload.
>>
>>  
>>
>> However, if the RTP is captured in a TURN-flow, as in TRAM Milestone
>> 3, the network point that this flow is directed to and can apply QoS
>> methods relevant to the network (which is not diffserve in Mobile OTT
>> and Cable Networks) has not a too difficult tasks. Linking each
>> RTP-flow by its ID and sequence number, and picking exactly the right
>> traffic type and bandwidth parameters is doable (see inline below, we
>> at Ingate do it already)!
>>
>>  
>>
>> Also DiffServ DSCP-bits are seldom maintained crossing network
>> boundaries, thus carrying no relevant information at the receiving
>> end, while the RTP extension header remains unchanged end-to-end. In
>> DSCP-bits, there is no bandwidth requirement information when
>> entering networks requiring reservation. That is always (and
>> dynamically set) available in the RTP extension header for each packet.
>>
>>  
>>
>> And, I am sure you are aware of the difficulties of getting DSCP-bits
>> through OS sockets, which is even worse with multiple streams over
>> the same UDP-port
>>
>>  
>>
>> Further, defining the QoS RTP extension header as in RFC5285, does
>> not in anyway conflict with other RTP extension headers or DSCP
>> transfer or settings.
>>
>>  
>>
>> /Karl
>>
>>  
>>
>> *Från:*Colin Perkins [mailto:csp@csperkins.org]
>> *Skickat:* den 24 februari 2014 23:52
>> *Till:* Karl Stahl
>> *Kopia:* rtcweb@ietf.org <mailto:rtcweb@ietf.org>; Magnus Westerlund;
>> tram@ietf.org <mailto:tram@ietf.org>; Harald Alvestrand
>> *Ämne:* Re: [rtcweb] [tram] Payload Types assignments
>>
>>  
>>
>> Karl,
>>
>>  
>>
>> I strongly disagree with this suggestion. An RTP header extension,
>> located at an unknown and variable offset into a packet that does not
>> have a well-defined magic number in the header,
>>
>> This is how to find the traffic info:
>>
>>    The payload of the classifier header extension element can be encoded
>>
>>    using either the one-byte or two-byte header defined in [rfc5285
>> <http://tools.ietf.org/html/rfc5285>] and
>>
>>    shown below in Figure 1 and 2 below.
>>
>>  
>>
>>       0                   1                   2                   3
>>
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |  ID   | len=1 |   Namespace   |    Value      |    0 (pad)    |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  
>>
>>              Figure 1: Classifier Using the One-Byte Header
>>
>>  
>>
>>       0                   1                   2                   3
>>
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>      |      ID       |    len=2      |   Namespace   |    Value      |
>>
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>  
>>
>>  
>>
>>              Figure 2: Classifier Using the Two-Byte Header
>>
>>  
>>
>> indicated using a dynamically assigned identifier that is conveyed in
>> an out-of-band
>>
>> --- It is the TURN flow!!! Requested by the ICE protocol for the
>> specific media to come!
>>
>> and encrypted signalling channel,
>>
>> --- Only the payload is encrypted in SRTP – leaving id, seq no and
>> header ext to be used as intended!
>>
>> --- Thus being the appropriate place…
>>
>> is not an appropriate place to put QoS information that has to be
>> processed on a per-packet basis.
>>
>> If you want DiffServ, you know where to find it.
>>
>> --- True, but if it cannot be used…
>>
>> Colin
>>
>>  
>>
>>  
>>
>> On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se
>> <mailto:karl.stahl@intertex.se>> wrote:
>>
>>     I suggest to the RTCWEB WG that the below from the September and
>>     October discussions on the relevant [rtcweb] [avtext]
>>     [mmusic]lists
>>     http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html
>>     is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC
>>     5285, to allow:
>>
>>      
>>
>>     (1) WebRTC applications to directly convey QoS related real-time
>>     traffic info to the network at points where RTP flow is directed
>>     to by TRAM Milstone 3, to be used by **any network element
>>     implementing any suitable QoS methods for the particular
>>     network** for
>>
>>     (2) **all** WebRTC browsers **and** clients, under **all** OSs,
>>     and **all** current and future IP network, to achieve best QoE
>>
>>     *(3) *without* *having to force WebRTC into application specific
>>     networks (such as IMS) instead of using the Internet (including OTT).
>>
>>      
>>
>>     The only further activity required, is to call for ISPs’ to
>>     review whether the traffic information transferred by RFC 5285 is
>>     sufficient for current and future needs in their network as
>>     suggested in below repeated
>>     http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html
>>
>>     <snip>
>>
>>     …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 for quality type 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.
>>
>>     </snip>
>>
>>      
>>
>>     Then this could be assigned numbers to have an RFC in place.
>>
>>      
>>
>>     With TRAM milestone 3 also place,
>>
>>     market forces will drive ISPs and browser makers to implement
>>     just this, without even having it MUST-established.
>>
>>      
>>
>>     “Who does not want a “WebRTC-Ready” Internet access?” and
>>
>>     “Who wants to use Chrome, if Firefox, Internet Explorer or Safari
>>     comes with much better QoE?” and vice versa.
>>
>>      
>>
>>     Please see further emails soon following this one, for details
>>     and history.
>>
>>      
>>
>>     /Karl
>>
>>      
>>
>>      
>>
>>     *Från:*rtcweb-bounces@ietf.org <mailto:rtcweb-bounces@ietf.org>
>>     [mailto:rtcweb-bounces@ietf.org] *För *Karl Stahl
>>     *Skickat:* den 22 oktober 2013 16:37
>>     *Till:* 'Harald Alvestrand'; rtcweb@ietf.org
>>     <mailto:rtcweb@ietf.org>; 'Magnus Westerlund'
>>     *Kopia:* 'Colin Perkins'
>>     *Ämne:* [rtcweb] [avtext] Payload Types assignments was Re: SV:
>>     [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>>
>>      
>>
>>     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 aren’t 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 let’s 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 <http://msdn.microsoft.com/en-us/library/cc431507%28v=office.12%29.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>
>>     [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand
>>
>>     Skickat: den 8 oktober 2013 13:01
>>
>>     Till: rtcweb@ietf.org <mailto: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 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 <mailto:rtcweb@ietf.org>
>>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>  
>>
>>  
>>
>> -- 
>>
>> Colin Perkins
>>
>> http://csperkins.org/
>>
>>  
>>
>>  
>>
>>  
>>
>
>
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>

-- 
Surveillance is pervasive. Go Dark.