Subject: [rtcweb] [tram] Payload Types assignments

From: "Karl Stahl" <[email-masked]>
Date: Mon, 24 Feb 2014 23:09:17 +0100

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: [email-masked] [mailto:[email-masked]] För Karl
Stahl
Skickat: den 22 oktober 2013 16:37
Till: 'Harald Alvestrand'; [email-masked]; '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 

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: [email-masked] [mailto:[email-masked]] För Harald
Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: [email-masked]

Ä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

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/rtcweb>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Feb 2014 22:52:04 +0000

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, indicated using a dynamically assigned identifier that is conveyed in an out-of-band and encrypted signalling channel, 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.

Colin

On 24 Feb 2014, at 22:09, Karl Stahl <[email-masked]> 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>
>  
> market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established.
>  
> “Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with much better QoE?” and vice versa.
>  
> Från: [email-masked] [mailto:[email-masked]] För Karl Stahl
> Ä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.
>  
> 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
> 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.
> Från: [email-masked] [mailto:[email-masked]] För Harald Alvestrand
> Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>  
> In, for instance, a shooter game with voice backchannels, the movement and event information (data) is MORE time sensitive than the voice data.
>  
> > 
> 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.
>  
> > 
> > connection we see Chrome reducing the video window size to reduce the bandwidth used...
> > 
> 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.
>  
> [email-masked]

-- 
Colin Perkins
http://csperkins.org/

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 25 Feb 2014 02:45:52 +0100

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:[email-masked]] 
Skickat: den 24 februari 2014 23:52
Till: Karl Stahl
Kopia: [email-masked]; Magnus Westerlund; [email-masked]; 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

<snip>

</snip>

/Karl

/Karl

...

§ "0x0001": Audio

§ "0x0002": Video

§ "0x0004": Data

 

-----Ursprungligt meddelande-----

Till: [email-masked]

bandwidth used...

rtcweb mailing list

 

-- 

Colin Perkins

http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Feb 2014 09:39:41 +0100

Karl,
(As individual)

I also wish for more usable QoS mechanisms. However, I don't see that
being achieved by your proposal. In addition I agree with Colin about
the issues with putting the information in the RTP header extension. I
would also note that this would be very RTP specific, and not at all
help with the data channels multiple streams and their priorities. There
might be data channel information that is more crucial than any of the
RTP media stream packets.

You are pushing for a small piece in the middle. A piece that will not
help with the more general issue of QoS. How does the application and
the multiple ISPs that carries the traffic reach an agreement on what
properties that can be provided, that the application in this instance
have the right to request those properties and that any cost is
correctly associated with the user or the user's agent in regards to
carrying the associated cost.

When it comes to setting DSCP from user land in the OS, that is
restricted due to the security implications. If those implications where
resolved, then OS could open up those interfaces.  There are many
interlinked reasons why things look like they do today. I don't believe
in tugging on a single random thread in ball of yarn and hope that it
comes out without any knots and ties on it.

Show me the framework for the QoS functions you have in mind that at
least has less issues than the currently deployed and take care of at
least some of the bigger issues. If that requires information in the RTP
streams for some reasons, then let us talk about how to best encoded it.
But, we need that framework first, the architecture that makes this a
better solution than the current Diffserv architecture or any other QoS
architecture.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 25 Feb 2014 15:52:19 +0000

It may have been mentioned previously, but those interested in this may
well want to have a look at the following drafts being discussed on the
AEON list ([email-masked]):

http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00
http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00

While QoS is not the sole focus of this work, it is one of the important
work flows prevalent in networks today that is more challenging in the
face of emerging communication applications such as those enabled by
WebRTC. One of the goals of the AEON effort is to provide a framework such
as the one mentioned by Magnus.
Comments on the AEON list are welcome, as is your attendance at the AEON
side meeting at IETF 89:
http://www.ietf.org/mail-archive/web/aeon/current/msg00018.html

Cheers,
Charles

On 2/25/14, 12:39 AM, "Magnus Westerlund" <[email-masked]>
wrote:

>tram mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tram

---

From: Colin Perkins <[email-masked]>
Date: Tue, 25 Feb 2014 23:49:01 +0000

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 <[email-masked]> 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
>  
> 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,
>    using either the one-byte or two-byte header defined in [rfc5285] and
> 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!
> --- Only the payload is encrypted in SRTP – leaving id, seq no and header ext to be used as intended!
> is not an appropriate place to put QoS information that has to be processed on a per-packet basis.

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 26 Feb 2014 04:48:47 +0100

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 <[email-masked]
> <mailto:[email-masked]>> 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.
>>
>>  
>>
>> 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:[email-masked]]
>> *Skickat:* den 24 februari 2014 23:52
>> *Till:* Karl Stahl
>> *Kopia:* [email-masked] <mailto:[email-masked]>; Magnus Westerlund;
>> [email-masked] <mailto:[email-masked]>; 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,
>>
>> <http://tools.ietf.org/html/rfc5285>] and
>>
>> On 24 Feb 2014, at 22:09, Karl Stahl <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     I suggest to the RTCWEB WG that the below from the September and
>>     October discussions on the relevant [rtcweb] [avtext]
>>     [mmusic]lists
>>     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
>>     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>
>>
>>      
>>
>>     market forces will drive ISPs and browser makers to implement
>>     just this, without even having it MUST-established.
>>
>>      
>>
>>     “Who wants to use Chrome, if Firefox, Internet Explorer or Safari
>>     comes with much better QoE?” and vice versa.
>>
>>      
>>
>>     *Från:[email-masked] <mailto:[email-masked]>
>>     [mailto:[email-masked]] *För *Karl Stahl
>>     *Skickat:* den 22 oktober 2013 16:37
>>     *Till:* 'Harald Alvestrand'; [email-masked]
>>     <mailto:[email-masked]>; '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".
>>
>>      
>>
>>     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.
>>
>>      
>>
>>     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”;
>>
>>     --- 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)
>>
>>     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./
>>
>>      
>>
>>      
>>
>>     Från: [email-masked] <mailto:[email-masked]>
>>     [mailto:[email-masked]] För Harald Alvestrand
>>
>>     Till: [email-masked] <mailto:[email-masked]>
>>
>>     Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic]
>>     WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11
>>
>>      
>>
>>     In, for instance, a shooter game with voice backchannels, the
>>     movement and event information (data) is MORE time sensitive than
>>     the voice data.
>>
>>      
>>
>>     > 
>>
>>     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.
>>
>>      
>>
>>     > 
>>
>>     If you need to know the bandwidth or the priority up front, the
>>     application has to tell you. Anything else is pure heuristics.
>>
>>      
>>
>>     [email-masked] <mailto:[email-masked]>
>>

-- 
Surveillance is pervasive. Go Dark.