Hi Pal,

Thank you for the go through below - I think that was very relevant/necessary and I have put some further thoughts inline, that spans even further.

In the email before this one, I asked Alan to elaborate on how this draft-thomson-tram-turn-bandwidth-00.txt relates to the QoS/QoE issues discussed here in TRAM. I actually think its purpose is to "convey polices" rather that traffic information for use by functions that can implement QoS/QoE remedies. 

In there I also "happened to describe" the main QoS/QoE issues and remedies (and how they work) in as short, simple and understandable way I am able to, and hope that may be beneficial for everyone to understand the underlying things of what is proposed and discussed here.

In case the discussion continuous on this thread, I also repeat the necessity to complete the QoS/QoE mission of TRAM and the A) B) C) D) steps I see in the standardization work to reach the goal. Maybe this can discussed in London?

<Repetition from another thread>
Let me also point out draft-deng-tram-isp-turn-00 
http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from China Mobile that appeared on this mailing list yesterday. It points out the need and willingness from the ISP/NSP side to do something about QoS for WebRTC traffic, that they expect to be large and have to bring to their customers with best QoE. In fact they and some more (a huge European carrier and the cable operators in general - CableLabs) have expressed similar concerns to me “This is exactly something we want to work on as the current way will cause severe problem on traffic when rtcweb applications get popular” is a direct quote from one of those.

So, in answer to Simon Perreault [simon.perreault@viagenie.ca]’s question in another thread the 13th:
a) Is this a real problem that is worth fixing?
I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe’s IP accesses! And the other will follow these most forward looking carriers. 

Even if the mission to bring quality to real-time traffic over our best effort Internet is a huge mission, I am convinced it not a huge task – We just be a bit clever here :). I only see these few standard steps required, before it can happen!

A) Auto-discovered TURN servers 
 
B) Enforcing the real-time traffic through the offered/discovered TURN servers 
(Discussed below: Detecting a flow is not enough – we need to enforce – more input below.) 

C) Providing real-time traffic information from the application/browser to the network element that has the flow and can apply QoS measures (that would be “the box containing the TURN server”**) 
(DISCUSS- or draft-thomson-tram-turn-bandwidth-00.txt-like methods are being discussed, but they do not do it all e.g. provide info of incoming traffic and varying bandwidth requirements of smart codecs.)

D) Adding real-time traffic information to the media packets themselves, to fix QoS where the above is not sufficient. This can both fix the lack of type and bandwidth info of incoming traffic (even varying) at the TURN points and also be of a great help across network boundaries/peering points, where DSCP-bits are changed and when going into reservation type of networks (cable and mobile) since DSCP-bits gives no clue of what bandwidth needs to be reserved. 

Here I see the recreation of the idea/intention of the RTP payload type (PT) header as the obvious (and only?) solution. (That payload type info is no longer available though, since we use dynamic payload types and the SDP where it says what it is all about, nowadays cannot be said to be available to the network (usually encrypted and somewhere else than the media flow). There is a trivial way of doing this although it has been “considered impossible”, see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html . 

It is simply to add the bandwidth requirement and traffic type into two parameters in the RTP header extension (which is visible in also in SRTP – it is outside the encrypted payload - and the network can read it). That information should also stay with the traffic (and not be changed around like DSCP bits). The application/browser will also be able to change this info during a call, e.g. to announce higher or lower bandwidth requirements of varying bandwidth type of codecs or from application measures taken by QoS feedback via RTCP. Further, these RTP extension header bits are easily set by any browser using any operating system (which is not the case with DSCP-bits).

This “trivial” thing is needed for the “huge mission” of “bringing quality to real-time traffic over the best effort Internet”.  A framework is even done in 
http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 . 

*Time to get it done!*


Don't forget the inline comments below -->

/Karl

Footnote **[Karl]* For similar reasons I have started to say things like “the box containing the TURN server”. We should not change the TURN server spec into including specific QoS methods to apply (like reservation, changing DSCP bits or applying traffic shaping mechanism). What is happening here is that we share the traffic information that the TURN server gets hold of, with a QoS applying function (that will be different for different networks) in “the same box”. With “the same box” I mean that we for now don’t care about the interface/commands for sharing information between the TURN server and the QoS applying function. There may be a future need to specify/standardize this, but if we start doing that now and in TRAM, we risk ending up in a 10-year process before having something in place (which without a spec automatically will happen in vendor’s product development, by putting the TURN server into already available “QoS applying function” boxes (like firewalls or the mobile DPI/PCRF combination).

*What we need to consider and specify, is only what traffic info is required (to be provided by the application/browser) for “QoS applying functions” in different networks (including the very common reservation types) to do job (i.e. giving us good QoE for real-time applications).*
<End Repetition from another thread>

-----Ursprungligt meddelande-----
Från: tram [mailto:tram-bounces@ietf.org] För Pal Martinsen (palmarti)
Skickat: den 19 februari 2014 10:48
Till: tram@ietf.org
Kopia: Muthu Arul Mozhi Perumal (mperumal); Oleg Moskalenko; Simon Perreault
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

Hi,

I like the idea of a bandwidth attribute telling the TURN server what to expect from that particular allocation. Especially when it comes to allocations that carry for example RTCP, BFCP and other “low chatter” data protocols. When it comes to more “elastic” media protocols (video especially) a static bandwidth attribute can be a bit problematic. This is somewhat described in the draft that burst above the maximum should be expected. But due to very good video encoding efficiency in for example a talking head only scenario, the bandwidth usage may be significantly lower than the maximum bandwidth the agent signalled in the allocation message. 

So how is this bandwidth attribute useful for the TURN server when signalled from the allocating agent? What can it do when the bandwidth is exceeded, and when does it know that the bandwidth is exceeded? There might be different network paths to the TURN server. One path may be congested well before any TURN bandwidth is exceeded. 

I am trying to argue that the possible choke point in the network is not necessarily where the TURN server is placed, and that reduces the usefulness of a bandwidth attribute in some scenarios. When it comes to draft-thomson-tram-turn-bandwidth we must be careful to explain what problems it solves. I am afraid that this attribute might be (miss?)used as a QoS solution on the entire media path.

[Karl] You hit the point here that concerned me when trying to catch up on the discussions. I asked Alan to clarify in the previous email.

One possible use case for this draft to solve is to get better pr session/call/?? bandwidth utilisation.  If for example a user pays to get 3Mbit through the TURN server. The users endpoint is capable of sending 1 audio and 3 video (Head, room and slides) streams and one BFCP stream. The agent needs to do 9 allocations (4xRTP, 4xRTCP, 1xBFCP), 5 of those allocations are very low bandwidth. The agent itself knows best how to utilise the remaining bandwidth, but how should we cope with changing needs. How do we signal; I know that I have 3Mbit available, and I am dynamically going to use that bandwidth over those 4 allocations, and by the way I have 5 more allocations that only needs a packet sent now and then.. (And yes I know of BUNDLE, but the media streams may not have the same src/dst IP)

Separate from QoS/QoE means we need to get in place. 

[Karl] Same. You hit the point here that concerned me when trying to catch up on the discussions. I asked Alan to clarify in the previous email. I don't think the draft-thomson-tram-turn-bandwidth-00.txt is meant cope with this.

When it comes to DSCP and ECN, as Simon point out putting them in a STUN attribute would help getting the values transported unmangled over the Internet. 

[Karl] When you say "putting them in a STUN attribute" do you also include the TURN allocate request (since TURN  is an extension of STUN and I believe the attributes you can use are exactly the same - correct me if I am wrong!)? (You have already confirmed this is possible elsewhere - I just want to bring in that usage here) It is TURN we to control where the flow goes, so this it is highly important that we can get the application's knowledge to the TURN-server having the traffic flow, and hopefully "in the same box"** having QoS functions to help/assure/control that we can the best QoE.


This is especially important in this scenario as a NAT sitting between the agent and the TURN server might ignore those bits when forwarding the packets. 

[Karl] Here you hit an important point again, stressing why it is good to use TURN server attributes to transfer information about the traffic to the point (the TURN-server box) where there are means to deal with quality things.

[Karl] Another way of doing this to mark each RTP packet with relevant information (which I saw necessary for the more difficult to solve how have knowledge of *incoming* real-time traffic, when DSCP usually are lost over the Internet). But it of course could be useful here also.

[Karl] The marking is RTP packet with relevant information for network elements to use, is recreating the payload type (PT) marking idea/intent of RTP packets (by now conveying bandwidth and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html (Step D above)


The remaining problem with DSCP is that there is no strict defining of what the bits actually means. Some definitions can be found in draft-dhesikan-tsvwg-rtcweb-qos, but it is likely that different ISPs or networks will use different values. As Muthu pointed out, this is essentially the motivation for the  draft-martinsen-tram-discuss draft.

[Karl] Step D above, putting the bandwidth and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html will greatly help/remedy this issue. Better than DSCP-bits are available and unchanged in every RTP packet, and they are easily by the application/browser without the concern that DSCP bits seldom can be conveyed through our OSs.

/Karl

.-.
Pål-Erik


_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram