Subject: Re: [rtcweb] [tram] Payload Types assignments

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Mar 2014 08:30:47 +0100

Hi Harald,

The answer to your question 26 of February:
> 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.

--- I didn’t mention “QoS” (*I want the QoS methods out!*), in my
protest/request 

http://www.ietf.org/mail-archive/web/tram/current/msg00304.html “It must be
a clear objective of the TRAM WG that ISPs/NSPs are allowed and encouraged
to route quality demanding WebRTC media into their IP pipes that are capable
of transporting real-time traffic without quality issues, using TURN
servers. 

The subject from the TRAM mailing initiation spells out:

*Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs*

The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be used
for the above purpose.

(The objective of the TRAM WG milestone 3 is *not only* to resolve
restrictive enterprise NAT/firewall traversal problem using TURN servers.)”

However, it is a way of "Interfacing to QoS", A level 3-5
IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff, which I
now have started under 

 <http://www.ietf.org/mail-archive/web/tram/current/msg00331.html>
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to
interface to lower level's QoS-stuff

You were September 20 actually the first to answer my request for a DHCP
provided turn server address (which I withdraw in favor of the anycast
method, which is highly preferable):

http://www.ietf.org/mail-archive/web/rtcweb/current/msg08920.html 

There I said:

>There are several reasons for a network service provider to supply a TURN

server as part of his offered access:

- to keep media paths short, specifically not sending media outside its own

network to some distant application provided TURN server

- to support mobility, i.e. you may want to move from a LAN with a

configured TURN server to accessing via WiFi or 3G/4G OTT channels

- to offer a media path with better quality (than best effort data traffic).

Getting a “WebRTC-ready” access and we can look forward to telepresence for

everyone.

I don’t really see anyone objecting to those objectives, and I don’t think
you do either.

The Anycast method were suggested October 22 (without further discussions)

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html 

and thereafter brought into TRAM WG list February 8 

http://www.ietf.org/mail-archive/web/tram/current/msg00132.html 

It took me some time to find the relevant emails from the discussions in
September and October which ended up with my entry to the [tram]-list
February 8, which is copied in full below, where I still say it was 95%
ready (There are a few relevant points from Simon that I will address
later). Thereafter, the QoS diversion and confusion started around February
12th in what looks to me as effort to make it a “Mission Impossible”.

I don’t know how the TRAM WG was created, but I thought Milestrone 3 was a
result of Cullen’s. See next email in response to Cullen’s questions and
requests.

/Karl

Footnote:

[1] I think both you (Harald) and Cullen, are good, have the best intentions
and integrity, but no one of us have infinite memory capacity (especially
when the VP8/H.264 flooding came in between). I only learned “by accident”
that the TRAM WG was in progress at the November WebRTC conference” and
should handle the Auto Discovery of TURN-servers.

Från: Karl Stahl [mailto:[email-masked]] 
Skickat: den 8 februari 2014 14:11
Till: [email-masked]'; [email-masked]'; 'Simon Perreault'
Ämne: [tram] Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Karl from Ingate and Intertex just added himself to this list for exactly
the purpose of the subject of Milestone 3 above 

I welcome this initiative that I saw yesterday after being reminded by China
Mobile Research Institute who had seen the previous October discussion on
the WebRTC-list, parts of which are inserted below. Large carriers have also
expressed the importance of this milestone.

--------------------

We are working on this draft, will publish it next week.

-Tiru.

Great, please consider the input and suggestions below:

> -----Original Message-----

> From: tram [ <mailto:tram-bounces> mailto:tram-bounces at ietf.org] On
Behalf Of Simon Perreault

> Sent: Friday, February 07, 2014 7:58 PM

> To: tram at ietf.org

> Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for

> enterprise and ISPs

…

> Enterprises or ISPs wishing to provide

> their own TURN server, in an attempt to reduce so-called "triangle
routing",

> need a new auto-discovery mechanism.

--- There are more reasons heard for auto-discovery of a network provided
TURN server:

- NSPs (Network Service Providers) want to provide a path where the
bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Internet access quality pipe for
prioritized RTC (Real Time Communication) traffic. 

- Enterprises having restrictive firewalls, want to provide a UDP-path for
WebRTC and possibly also for better quality where RTC do not compete with
data traffic. 

- Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G
OTT channels, all should be able to automatically offer their own optimal
TURN server

- Note that to achieve some of the above points, TURN must be favored over
STUN to enforce that the TURN-path actually is used. (The Anycast method
suggested below, “automatically” does this.) 

-- In my view, a TURN server is the network providers’ responsibility to
provide (just like the IP address, the default gateway, the DNS etc.) –
rather than the application provider’s. Our current Internet accesses may
not cope with or be optimized for WebRTC usage – The NSP (or Enterprise LAN
administrator) should then be able to fix the access (here by offering a
TURN server). 

> IMHO this is also a top-priority milestone. We need to quickly have a

> mechanism that people can implement in WebRTC browsers now, while

> there is still frenetic development happening. 

--- Agree

I don't foresee actual server-

> side deployment happening quickly though. But as soon as clients are
ready,

> any ISP or enterprise can deploy and immediately benefit.

- There is a definitive interest among forward SPs already, especially
carriers owning the network.

(They have learned that their networks (especially mobile) seem to become
data crowded no matter how much bandwidth they invest in.)

> I imagine that the solution will be fairly simple, spec- and
implementation-

> wise. 

--- Agree that such solution should and could be found, but it is not
obvious. Below you find 3 proposals (initiated by me or colleagues, where I
see flaws in the two first and now only suggest the third (the Anycast
mechanism). From below:

- 1st: … withdraw my suggestion to use DHCP to find a network provider
offered TURN server in favor of the DNS-Based Service Discovery method
(inserted last below). The major problem with the DHCP usage was that you
then also have to do something similar for: RA - Router Advertisement - in
IPv6, addition to the IPCP protocol for PPPoE and something for the mobile
OTT channel – wherever DHCP is NOT the method to give you an IP address.
(There were also concerns whether OSs actually supports forwards such
extended DHCP information for the browser to use.)

- 2nd Reverse DNS-Based Service Discovery method:

Justin Uberti pointed out:  How does this get bootstrapped? That is, how is
the STUN server found?

[Karl] Oops, that got lost when leaving the DHCP track, and is a problem
when using DNS discovery.

(There were also hesitations of having to provision this special reverse DNS
for every access.)

- 3rd The Anycast method below – I see no problem

It also has the advantage of encouraging (but not requiring) the STUN/TURN
to be built in the default gateway or NAT/firewall/access router itself,
with a second interface to a public IP address on the WAN side. (Current
volume deployed, low cost NSP triple play modems usually have a quality
assured level 2 or level 3 WAN pipe for just voice (and another for IPTV) –
The anycast discovered TURN-server can be the access gateway to such quality
pipe for WebRTC media, in a single NSP provided CPE, scaling from
residential and up.)

So I think we can finish this very quickly once we have a candidate

> draft. We just need authors. So I would target not long after Toronto.

> Simon

WEB BROWSER BEHAVIOUR:

Network provided TURN servers will not appear over night, applications may
for long provide a TURN server address, and there are exceptions where the
TURN server address is preferred to be “manually” configured. It is
previously suggested, and to some extent discussed, that the WebRTC browser
should select the TURN server to use in the following priority order, where
ICE would assure that you get some connectivity if several candidates are
found and needs to be tested:

1) TURN server address configured in the browser by the user (special cases,
normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an “admin
policy template” or a WPAD method as mentioned below

3) TURN server address auto-discovered by the mechanism discussed here

4) TURN server address being supplied by the web application

With a good step 3), step 2) becomes obsolete since the network
administrator e.g. simply can set a route in the enterprise firewall to use
the Anycast mechanism instead. 

Even if the need for auto-discovery of the TURN server comes from WebRTC
usage, a general mechanism that also can be used by SIP clients (and other
protocols using TURN via ICE) is preferable. The anycast method has no
application dependence, but e.g. WPAD has (a SIP Client typically does not
have the luxury of a JS engine…)

/Karl

Från: tram [mailto:[email-masked]] För Harald Alvestrand
Skickat: den 26 februari 2014 04:49
Till: Colin Perkins; Karl Stahl
Kopia: Magnus Westerlund; [email-masked]; [email-masked]
Ämne: Re: [tram] [rtcweb] 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.

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Mar 2014 10:02:25 +0100

For the “mission to bring quality to real-time traffic over our best effort
Internet” I have started
<http://www.ietf.org/mail-archive/web/tram/current/msg00331.html>
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

[tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5
IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff [1] [2]

Hi Magnus,

With the response just sent to Pål
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, skipping
all the QoS methods and functions that really does not belong here when
creating an “Interface to QoS”, I only see the suggestion of “data channel
information”, i.e. also marking each data channel packet with traffic
bandwidth and type information  to be relevant and interesting. I checked
with one of our developers and I think the same traffic information as for
RTP can be transferred in data channel packets as follows:

The RTP header has the following format (RFC 3550):

    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |V=2|P|X|  CC   |M|     PT      |       sequence number         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

RTP Payload (often encrypted)

A Data Channel header could have the following format:

    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   Data Channel Magic Cookie   |      (sequence number)        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                           timestamp                           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           synchronization source (SSRC) identifier            |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            contributing source (CSRC) identifiers             |

   |                             ....                              |

   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

   |            RFC5285 header extension ...                      |

   |     2 bytes Max Bandwidth     |   2 bytes Traffic Type        |

   |                             ....                              |

  DTLS Header 13 bytes

  SCTP

The RFC5285 header extension is not in a fixed position in any of these
cases, but still trivial to find (especially when in  a TURN flow). This
could be introduced in
http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-5 

by making room for these bytes after the UDP header, but before the DTLS
header.

What do you think?

Please apply the thought that we must allow ISPs/NSPs to route the WebRTC
media to where it can be handled, by using TURN servers. A TURN server in a
QoS-box can then use the traffic info (max bandwidth and traffic type) found
in the extension header, to do whatever QoS method or function that is
appropriate for the specific network type (none discriminated). 

Regarding what to encode, I have several times suggested, e.g.

already October 22
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

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(2 bits),
Variation Y(2 bits), that could be combined as required to describe the
stream.

And with the 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 provide what more you see required (for any QoS method/function for
any network type)!

/Karl

Footnotes:

[1] Please do not divert or confuse this with QoS methods in themselves
(like diffserve, bandwidth reservation, congestion control etc.) This is the
interface from the application to the network level, where all networks
types should be able to use the traffic information for QoS methods relevant
to the particular network.

[2] Here it is about recreation of the idea/intention of the RTP payload
type (PT) header that is not available for the network level anymore, by
instead having the application/browser filling the RTP header extension with
relevant traffic info that all IP network types can use. Here, similar
traffic type marking is suggested for the data channel.

-----Ursprungligt meddelande-----
Från: Magnus Westerlund [mailto:[email-masked]] 
Skickat: den 25 februari 2014 09:40
Till: Karl Stahl
Kopia: [email-masked]; [email-masked]
Ämne: Re: SV: [rtcweb] [tram] Payload Types assignments

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. 

--- Not at all! I am pushing for "Interfacing to QoS" rather mixing the
application layer directly to lower level QoS methods like setting DSCP bits
etc..

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:
<mailto:[email-masked]> [email-masked]

----------------------------------------------------------------------

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Mar 2014 10:24:11 +0100

Hi Colin,

Please see the just sent email to Pål and Magnus where I address your
concerns. 

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11847.html

/Karl

Footnotes:

[2] Here it is about recreation of the idea/intention of the RTP payload
type (PT) header that is not available for the network level anymore, by
instead having the application/browser filling the RTP header extension with
relevant traffic info that all IP network types can use. Similar traffic
type marking is suggested for the data channel.

Från: Colin Perkins [mailto:[email-masked]] 
Skickat: den 26 februari 2014 00:49
Till: Karl Stahl
Kopia: [email-masked]; Magnus Westerlund; [email-masked]; Harald Alvestrand
Ämne: Re: [rtcweb] [tram] Payload Types assignments

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

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

     |  ID   | len=1 |   Namespace   |    Value      |    0 (pad)    |

             Figure 1: Classifier Using the One-Byte Header

      0                   1                   2                   3

     |      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 <[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:

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:

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

-- 

Colin Perkins

http://csperkins.org/

 

-- 

Colin Perkins

http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Mar 2014 16:38:25 +0100

On 03/13/2014 10:02 AM, Karl Stahl wrote:
>
> For the"mission to bring quality to real-time traffic over our best 
> effort Internet" I have started 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11846.html, 
> skipping all the QoS methods and functions that really does not belong 
> here when creating an "Interface to QoS", I only see the suggestion of 
> "data channel information", i.e. also marking each data channel packet 
> with traffic bandwidth and type information  to be relevant and 
> interesting. I checked with one of our developers and I think the same 
> traffic information as for RTP can be transferred in data channel 
> packets as follows:
>
> The RFC5285 header extension is not in a fixed position in any of 
> these cases, but still trivial to find (especially when in  a TURN 
> flow). This could be introduced in 
> by making room for these bytes after the UDP header, but before the 
> DTLS header.
>
> What do you think?
>

No.

We've chosen to make Data Channel a protocol within DTLS, and not use 
any unencrypted headers for it. Neither does the data channel have any 
concept resembling SSRC, CSRC or timestamp. Changing to an RTP-based 
format such as the one you propose would be a drastic revision of the spec.

There's no reason to believe such a revision at this time has any 
traction in the WG.