Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

From: Alan Johnston <[email-masked]>
Date: Mon, 17 Feb 2014 14:13:36 -0600

All,

We have written a new I-D on a bandwidth attribute for TURN.  The use case
is to allow a TURN client to indicate to the server the bandwidth it
expects to use for the relayed candidate, or for a TURN server to indicate
to the client the maximum bandwidth before the TURN server might apply rate
limiting.

Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which
was discussed in the past, but this draft does not propose an ICE use case
for consent.

Comments most welcome!

- Alan -

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : A Bandwidth Attribute for TURN
        Authors         : Martin Thomson
                          Bernard Aboba
                          Alan Johnston
                          Oleg Moskalenko
        Filename        : draft-thomson-tram-turn-bandwidth-00.txt
        Pages           : 8
        Date            : 2014-02-13

Abstract:
   An attribute is defined for Session Traversal Utilities for NAT
   (STUN) that allows for declarations of bandwidth limits on the
   negotiated flow.  The application of this attribute is the
   negotiation of bandwidth between a Traversal Using Relays around NAT
   (TURN) client and a TURN server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 18 Feb 2014 16:38:23 +0000

I think a Traffic Type attribute (audio, video, data) in addition to Bandwidth would help the TURN server make better decisions about the policies described in the draft, and in particular to the following one:

    A TURN server might also wish to limit the use of service
    to audio-only sessions, or low bandwidth video and audio
    sessions.

It might also help SPs who would like to host TURN servers to provide differentiated treatment for WebRTC media traffic.

Of course, there would have to a discussion on what if the application is lying about these..

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: [email-masked]
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

All,

We have written a new I-D on a bandwidth attribute for TURN.  The use case is to allow a TURN client to indicate to the server the bandwidth it expects to use for the relayed candidate, or for a TURN server to indicate to the client the maximum bandwidth before the TURN server might apply rate limiting.

Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which was discussed in the past, but this draft does not propose an ICE use case for consent.

Comments most welcome!

- Alan -
---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: [email-masked]<mailto:[email-masked]>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 18 Feb 2014 11:53:39 -0600

Muthu,

Thanks for the feedback on the draft.

I agree that some kind of traffic type indication could also be useful for
the TURN client to indicate to the TURN server the nature of the relayed
traffic.  The TURN server could do this implicitly based on the bandwidth,
although it might have difficulty distinguishing a high quality voice
session from a low quality video session.

Using this indication for QoS could be problematic as you point out, if
TURN clients lie about the nature of the traffic to get a higher priority
than they would otherwise.

- Alan -

On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

 I think a Traffic Type attribute (audio, video, data) in addition to
> Bandwidth would help the TURN server make better decisions about the
> policies described in the draft, and in particular to the following one:
>
>
>
> It might also help SPs who would like to host TURN servers to provide
> differentiated treatment for WebRTC media traffic.
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Alan Johnston
> *Sent:* Tuesday, February 18, 2014 1:44 AM
> *To:* [email-masked]
> *Subject:* [tram] Fwd: I-D Action:
> draft-thomson-tram-turn-bandwidth-00.txt
>
>
>
> All,
>
>
>
> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>directories:
> http://www.ietf.org/shadow.html

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Feb 2014 09:55:36 -0800

I am not sure about further detalization of the traffic... the next step
would be codec number, type of data (social networks or finance apps), etc
- where to stop ?

Oleg

On Tue, Feb 18, 2014 at 8:38 AM, Muthu Arul Mozhi Perumal (mperumal) <
[email-masked]> wrote:

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Feb 2014 13:22:22 -0500

Le 2014-02-18 11:38, Muthu Arul Mozhi Perumal (mperumal) a écrit :
> policies described in the draft

Isn't DSCP already sufficient? Nothing prevents the TURN server from
actually using the stuff...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Feb 2014 13:12:46 -0800

How to handle the DS and ECN fields is a part of TURN server RFC (see the
section 12):

http://tools.ietf.org/search/rfc5766#section-12

And a good TURN server is supposed to implement that.

Regards,
Oleg

---

From: Simon Perreault <[email-masked]>
Date: Tue, 18 Feb 2014 16:33:00 -0500

Le 2014-02-18 16:12, Oleg Moskalenko a écrit :
> How to handle the DS and ECN fields is a part of TURN server RFC (see
> the section 12):
> 

Well, the RFC just says that the TURN server should copy the DSCP from
one side to the other when doing en/de-capsulation. It doesn't say that
the server should actually do QoS based on the DSCP. My point is that
there's nothing preventing the server from actually doing it.

Anyway, I was expecting responses along the lines of "DiffServ doesn't
work on the Internet in general." To which I would have replied: "then
couldn't we define a STUN attribute for transporting the DSCP in the
payload?" Instead of inventing a new taxonomy (audio, video, slides,
etc.), why not reuse DSCP?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Feb 2014 13:46:48 -0800

> etc.), why not reuse DSCP?
That would make sense - as s solution that does not require the TURN server
to be too smart but that allows some "easy" traffic engineering.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Feb 2014 17:04:02 -0500

On 2/18/14 4:46 PM, Oleg Moskalenko wrote:
>
>
>
> On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> That would make sense - as s solution that does not require the TURN
> server to be too smart but that allows some "easy" traffic engineering.

There is draft-ietf-mmusic-traffic-class-for-sdp-04 (recently expired).

It would have to be adapted to be fitted into TURN, but it provides a 
taxonomy.

	Thanks,
	Paul

---

From: Oleg Moskalenko <[email-masked]>
Date: Tue, 18 Feb 2014 14:08:38 -0800

TURN/STUN has been a binary protocol, so far... bringing SDP into the
picture would make it too complicated.

Thanks
Oleg

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Feb 2014 17:35:04 -0500

> picture would make it too complicated.

I didn't mean that. I just meant that the taxonomy could potentially be 
adopted in some way.

(Whether that is a good idea is another story. I haven't followed the 
work closely. It isn't obvious to me that the particular taxonomy is 
well justified.)

	Thanks,
	Paul

> Thanks
> Oleg
>
>
> On Tue, Feb 18, 2014 at 2:04 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>     There is draft-ietf-mmusic-traffic-__class-for-sdp-04 (recently
>     expired).
>
>     It would have to be adapted to be fitted into TURN, but it provides
>     a taxonomy.
>
>              Thanks,
>              Paul
>
>
>     _________________________________________________
>     tram mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 19 Feb 2014 03:52:33 +0000

Hi Alan,

Inline [TR]

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 11:24 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

Muthu,

I agree that some kind of traffic type indication could also be useful for the TURN client to indicate to the TURN server the nature of the relayed traffic.  The TURN server could do this implicitly based on the bandwidth, although it might have difficulty distinguishing a high quality voice session from a low quality video session.

Using this indication for QoS could be problematic as you point out, if TURN clients lie about the nature of the traffic to get a higher priority than they would otherwise.

[TR] Since TURN authentication is always used. TURN server can enforce per user limits and even if the application lies saying all the flows need high priority it would only impact the user's bandwidth and it should not impact other users.

-Tiru

- Alan -

On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) <[email-masked]<mailto:[email-masked]>> wrote:

Muthu

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

All,

Comments most welcome!

- Alan -
---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: [email-masked]<mailto:[email-masked]>

Abstract:

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 19 Feb 2014 04:19:35 +0000

draft-ietf-rtcweb-qos defines the recommended DSCP values for browsers to use for various classes of traffic. If the TURN server can use that, great. If on the other hand, the OS doesn't allow the browser to set it or the value gets reset, defining a STUN attribute on the same lines makes sense. I just realized draft-martinsen-tram-discuss (DISCUSS) already does that. The difference being it doesn't limit those attributes to TURN messages alone, but can certainly be carried in a TURN Allocate request and used by the TURN server.

Muthu

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Wednesday, February 19, 2014 3:17 AM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
Le 2014-02-18 16:12, Oleg Moskalenko a écrit :

That would make sense - as s solution that does not require the TURN server to be too smart but that allows some "easy" traffic engineering.

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 19 Feb 2014 09:47:54 +0000

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. 

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)

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. 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. 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.

.-.
Pål-Erik

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Feb 2014 08:34:17 -0500

> work closely. It isn't obvious to me that the particular taxonomy is

And we need to keep in mind that TURN is a generic traversal mechanism
usable by more than just real-time media...

Simon

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 20 Feb 2014 14:36:30 +0100

Hi Alan,

Can you comment/elaborate on the purpose and intended usage of this
draft-thomson-tram-turn-bandwidth-00.txt?

I am not clear about how the negotiation of bandwidth between a TURN client
and a TURN server can be useful considering how bandwidth is shared on the
Internet today and the QoS/QoE implications of this.
 
On this mailing list, this draft has been discussed as useful for QoS/QoE
improvement, which I cannot see it is. For such purposes, richer information
than the total bandwidth needs to be conveyed to the TURN server / network,
compare e.g. DISCUSS/MALICE
<http://tools.ietf.org/html/draft-martinsen-tram-discuss-00>
http://tools.ietf.org/html/draft-martinsen-tram-discuss-00.
 
In the Introduction of draft-thomson-tram-turn-bandwidth-00.txt:
   The operator of a TURN server will likely wish to provide fairness
   between relayed sessions.  A TURN server might also wish to limit the
   use of service to audio-only sessions, or low bandwidth video and
   audio sessions.  In addition, the server may apply rate-limiting
   policy depending on the credential used for authentication, or the
   origin of the client.  Without the BANDWIDTH attribute, there is no
   way for a client to indicate the expected bandwidth utilization, or
   for the server to indicate the maximum bandwidth utilization allowed
   before rate limiting could be applied.
 
I interpret that this draft is about conveying a “fairness policy” etc. to
the TURN server / network, without specifying how this could be realized or
implemented. Correct? More is needed for a possible the realization
considering QoS/QoE.
 
If richer information is needed for the realization, that may be the
attributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see
discussion in previous email).
 
On the other hand, if the information conveyed here
(draft-thomson-tram-turn-bandwidth-00.txt) already is available (directly or
indirectly) in the DISCUSS attributes, maybe we could end up with a single
draft that includes the real-time traffic information and sharing policy
that needs to be conveyed to the TURN server / network? Is that something to
consider?
 
Or if recreating the payload type (PT) idea/intent in 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>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is
sufficient for QoS/QoE in combination with auto-discussed TURN servers,
maybe draft-thomson-tram-turn-bandwidth-00.txt is the only thing we need in
addition (not the DISCUSS attributes).

For better understanding of these QoS/QoE problems, and methods for
improving (not specifically discussing the policies of sharing real-time
traffic space), I would like to explain:
 
Over an IP pipe only used for real-traffic (no TCP data traffic), it is
sufficient that the pipe is wide enough for good QoS. That is often used and
implemented by separating IP pipes at a lower level using e.g. Ethernet
VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can
enforce real-traffic into such pipes and QoS is achieved. Let’s call this
Level 2 QoS (Network level)
 
Over an IP pipe shared between quality requiring real-time traffic and less
demanding data or streaming (usually TCP) traffic, we have the sharing
between these two traffic classes to consider. The main method (and the
mechanism making today’s real-time QoE as good as it often is) is that TCP
endpoints back-off and share their bandwidth usage. Real-time traffic using
UDP transport do not back-off, the endpoints using UDP occupy the bandwidth
needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth
usage that is back-off and shared between them, leaving room for the UDP
traffic. This is mechanism we experience everyday over the Internet, using
our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)
 
However, this Level 4 QoS is based on that at congestion times (which happen
every time we click – setting up a TCP flow and transferring some amount of
data as quick as possible) the router handling the most narrow part of the
pipe (the congestion point) drop packets. It is this packet dropping that
(i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error
correction/retransmission mechanism) and (ii) destroys the QoE of real-time
traffic. (Both TCP and UDP packets are dropped in this process that is
triggered by flow intensive TCP traffic.)
 
We need (i) but don’t want (ii) and to improve on this we can e.g. use
diffserve, DSCP bits in IP packets to instruct routers to always forward the
real-time traffic before any unmarked TCP traffic (which usually fills most
of the pipe). Then QoS is then achieved for real-time traffic. This is Level
3 QoS (IP level). The method used is “traffic shaping”: backing off data
traffic, leaving real-time traffic free passage without packet loss.
 
Here, in TRAM we want to go beyond Level 4 QoS (already available and
working as good as it can on the Internet), to give quality demanding WebRTC
real-time traffic better QoE by:
a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using
auto-discovered TURN servers) 
or

b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using
auto-discovered TURN servers). Here we must have traffic shaping mechanisms
working, and with correct and sufficient information to do the job. This is
why we in TRAM discuss DISCUSS/MALICE,
draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the
payload type (PT) idea/intent in 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>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html.

How these QoS/QoE things are done and used in practice is also
illustrated/exemplified in this email discussion:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html 
 
Prioritization of individual real-time packets (e.g. using diffserve DSCP
bits) have today little impact on the QoE, UNLESS a pipe full with only
real-time traffic (which is unusual), because in today’s IP pipes with high
bandwidth, packets are not stored for later delivery, but rather dropped by
routers implementing diffserve (after only a short time period = small
buffer size). The only good remedy is higher bandwidth, that can handle ALL
real-time traffic. 
 
Prioritization of real-time packets (any diffserve DSCP bits marking) “makes
QoS perfect”, when there are best effort (=no DSCP bits set) TCP (=non
real-time) traffic going over the IP pipe that can be pushed off. Routers
implementing diffserve do that.

Having gone through all of this, I want to point out that the huge mission
to bring quality to real-time traffic over our best effort Internet, is not
a question of huge investments in new bandwidth (that happens anyway for
data and streaming video needs) or about sharing bandwidth (bandwidth is
available in access if we only consider the real-time need). It is about
borrowing some already existing bandwidth from data usage. And there are
only unnoticeable consequences of this borrowing; A delay of a fraction of a
second or so for click-responses or watching a movie. So the huge mission,
may be a an easy task if we do it cleverly.

And finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.txt
seems is related to how to request or buy or limit or pay for access to the
good real-time IP pipes for best QoE.
 
Isn’t that the case Alan, rather than intended to be used as QoS/QoE
improvement method (as it has been discussed).
 
/Karl

Från: tram [mailto:[email-masked]] För Alan Johnston
Skickat: den 17 februari 2014 21:14
Till: [email-masked]
Ämne: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

All,

We have written a new I-D on a bandwidth attribute for TURN.  The use case
is to allow a TURN client to indicate to the server the bandwidth it expects
to use for the relayed candidate, or for a TURN server to indicate to the
client the maximum bandwidth before the TURN server might apply rate
limiting.

Comments most welcome!

- Alan -

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: [email-masked]

Abstract:

<https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Draft>

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 20 Feb 2014 14:40:33 +0100

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 [[email-masked]]’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:[email-masked]] För Pal Martinsen (palmarti)
Skickat: den 19 februari 2014 10:48
Till: [email-masked]
Kopia: Muthu Arul Mozhi Perumal (mperumal); Oleg Moskalenko; Simon Perreault
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

Hi,

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

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 20 Feb 2014 08:26:18 -0600

Hi Karl,

Thanks for your comments and feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS.
 It is about fairness between users of a TURN server, and a TURN server
being able to indicate rate limiting policy to users.

Personally, I am not sure how much QoS is actually in scope for TRAM. Have
you been following RMCAT where congestion avoidance for RTP is being
developed?  I see some overlap in your goals and the goals of that work.

- Alan -

On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl <[email-masked]> wrote:

> I am not clear about how the negotiation of bandwidth between a TURN client and a TURN server can be useful considering how bandwidth is shared on the Internet today and the QoS/QoE implications of this.
>
>
>
> On this mailing list, this draft has been discussed as useful for QoS/QoE improvement, which I cannot see it is. For such purposes, richer information than the total bandwidth needs to be conveyed to the TURN server / network, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-tram-discuss-00.
>
>
>
> I interpret that this draft is about conveying a "fairness policy" etc. to the TURN server / network, without specifying how this could be realized or implemented. Correct? More is needed for a possible the realization considering QoS/QoE.
>
>
>
> If richer information is needed for the realization, that may be the attributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see discussion in previous email).
>
>
>
> On the other hand, if the information conveyed here (draft-thomson-tram-turn-bandwidth-00.txt) already is available (directly or indirectly) in the DISCUSS attributes, maybe we could end up with a single draft that includes the real-time traffic information and sharing policy that needs to be conveyed to the TURN server / network? Is that something to consider?
>
>
>
> Or if recreating the payload type (PT) idea/intent in 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 is sufficient for QoS/QoE in combination with auto-discussed TURN servers, maybe draft-thomson-tram-turn-bandwidth-00.txt is the only thing we need in addition (not the DISCUSS attributes).
>
>
>
>
>
> For better understanding of these QoS/QoE problems, and methods for improving (not specifically discussing the policies of sharing real-time traffic space), I would like to explain:
>
>
>
> Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can  enforce real-traffic into such pipes and QoS is achieved. Let's call this Level 2 QoS (Network level)
>
>
>
> Over an IP pipe shared between quality requiring real-time traffic and less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today's real-time QoE as good as it often is) is that TCP endpoints back-off and share their bandwidth usage. Real-time traffic using UDP transport do not back-off, the endpoints using UDP occupy the bandwidth needed. When an IP pipe gets filled, it is all endpoint's TCP bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, using our "Surf IP pipes". Let's call this Level 4 QoS (Transport level)
>
>
>
> However, this Level 4 QoS is based on that at congestion times (which happen every time we click - setting up a TCP flow and transferring some amount of data as quick as possible) the router handling the most narrow part of the pipe (the congestion point) drop packets. It is this packet dropping that (i) signals to TCP endpoints to reduce their bandwidth (via TCP's error correction/retransmission mechanism) and (ii) destroys the QoE of real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.)
>
>
>
> We need (i) but don't want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward the real-time traffic before any unmarked TCP traffic (which usually fills most of the pipe). Then QoS is then achieved for real-time traffic. This is Level 3 QoS (IP level). The method used is "traffic shaping": backing off data traffic, leaving real-time traffic free passage without packet loss.
>
>
>
> Here, in TRAM we want to go beyond Level 4 QoS (already available and working as good as it can on the Internet), to give quality demanding WebRTC real-time traffic better QoE by:
>
> a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using auto-discovered TURN servers)
>
> or
>
> payload type (PT) idea/intent in RTP packets (by now conveying bandwidth
> and traffic type in the RTP extension header
> How these QoS/QoE things are done and used in practice is also illustrated/exemplified in this email discussion:
>
> Prioritization of individual real-time packets (e.g. using diffserve DSCP bits) have today little impact on the QoE, UNLESS a pipe full with only real-time traffic (which is unusual), because in today's IP pipes with high bandwidth, packets are not stored for later delivery, but rather dropped by routers implementing diffserve (after only a short time period = small buffer size). The only good remedy is higher bandwidth, that can handle ALL real-time traffic.
>
>
>
> Prioritization of real-time packets (any diffserve DSCP bits marking) "makes QoS perfect", when there are best effort (=no DSCP bits set) TCP (=non real-time) traffic going over the IP pipe that can be pushed off. Routers implementing diffserve do that.
>
>
>
>
>
> Having gone through all of this, I want to point out that the huge mission to bring quality to real-time traffic over our best effort Internet, is not a question of huge investments in new bandwidth (that happens anyway for data and streaming video needs) or about sharing bandwidth (bandwidth is available in access if we only consider the real-time need). It is about borrowing some already existing bandwidth from data usage. And there are only unnoticeable consequences of this borrowing; A delay of a fraction of a second or so for click-responses or watching a movie. So the huge mission, may be a an easy task if we do it cleverly.
>
>
>
>
>
> And finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.txt seems is related to how to request or buy or limit or pay for access to the good real-time IP pipes for best QoE.
>
>
>
> Isn't that the case Alan, rather than intended to be used as QoS/QoE improvement method (as it has been discussed).
>
>
>
> /Karl
>
>
>
>
>
>
>
> *Från:* tram [mailto:[email-masked]] *För *Alan Johnston
> *Skickat:* den 17 februari 2014 21:14
> *Till:* [email-masked]
> *Ä**mne:* [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
>
>
>
> All,
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 20 Feb 2014 09:30:27 -0800

QoS does not even appear in the TRAM charter:
https://datatracker.ietf.org/doc/charter-ietf-tram/

While some of the pieces we are building may be useful for QoS, it is not
an explicit goal of this WG, and I would prefer to focus on the concrete
milestones that have already been identified.

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <[email-masked]>wrote:

> On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl <[email-masked]>wrote:
>
>> Hi Alan,
>>
>>
>>
>> I interpret that this draft is about conveying a “fairness policy” etc. to the TURN server / network, without specifying how this could be realized or implemented. Correct? More is needed for a possible the realization considering QoS/QoE.
>>
>>
>>
>> Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can  enforce real-traffic into such pipes and QoS is achieved. Let’s call this Level 2 QoS (Network level)
>>
>>
>>
>> Over an IP pipe shared between quality requiring real-time traffic and less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today’s real-time QoE as good as it often is) is that TCP endpoints back-off and share their bandwidth usage. Real-time traffic using UDP transport do not back-off, the endpoints using UDP occupy the bandwidth needed. When an IP pipe gets filled, it is all endpoint’s TCP bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, using our “Surf IP pipes”. Let’s call this Level 4 QoS (Transport level)
>>
>>
>>
>> However, this Level 4 QoS is based on that at congestion times (which happen every time we click – setting up a TCP flow and transferring some amount of data as quick as possible) the router handling the most narrow part of the pipe (the congestion point) drop packets. It is this packet dropping that (i) signals to TCP endpoints to reduce their bandwidth (via TCP’s error correction/retransmission mechanism) and (ii) destroys the QoE of real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.)
>>
>>
>>
>> We need (i) but don’t want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward the real-time traffic before any unmarked TCP traffic (which usually fills most of the pipe). Then QoS is then achieved for real-time traffic. This is Level 3 QoS (IP level). The method used is “traffic shaping”: backing off data traffic, leaving real-time traffic free passage without packet loss.
>>
>>
>>
>> Prioritization of individual real-time packets (e.g. using diffserve DSCP bits) have today little impact on the QoE, UNLESS a pipe full with only real-time traffic (which is unusual), because in today’s IP pipes with high bandwidth, packets are not stored for later delivery, but rather dropped by routers implementing diffserve (after only a short time period = small buffer size). The only good remedy is higher bandwidth, that can handle ALL real-time traffic.
>>
>>
>>
>> Prioritization of real-time packets (any diffserve DSCP bits marking) “makes QoS perfect”, when there are best effort (=no DSCP bits set) TCP (=non real-time) traffic going over the IP pipe that can be pushed off. Routers implementing diffserve do that.
>>
>>
>>
>>
>>
>> Isn’t that the case Alan, rather than intended to be used as QoS/QoE improvement method (as it has been discussed).
>>
>>
>>
>> /Karl
>>
>>
>>
>>
>>
>>
>>
>> We have written a new I-D on a bandwidth attribute for TURN.  The use
>> case is to allow a TURN client to indicate to the server the bandwidth it
>> Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent
>> which was discussed in the past, but this draft does not propose an ICE use
>> case for consent.
>>
>>
>>
>> Comments most welcome!
>>
>>
>>
>> - Alan -
>>

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Feb 2014 09:42:38 -0800

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <[email-masked]>wrote:

> -
I'd concentrate on the TURN application-level functionality, for now, and
I'd leave QoS for the future discussions.

---

From: "Yoakum, John H (John)" <[email-masked]>
Date: Thu, 20 Feb 2014 18:55:52 +0000

+1
I fully agree with the comments that QOS should be a low priority for the initial focus of the TRAM efforts.  There are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues.  I am more concerned about carriers doing things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them.

Significant focus on QOS before we better enable TURN to be easily used in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point.

Cheers,
John

AVAYA
1.919.425.8446

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; [email-masked]
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <[email-masked]<mailto:[email-masked]>> wrote:

Personally, I am not sure how much QoS is actually in scope for TRAM. Have you been following RMCAT where congestion avoidance for RTP is being developed?  I see some overlap in your goals and the goals of that work.
-

I'd concentrate on the TURN application-level functionality, for now, and I'd leave QoS for the future discussions.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 20 Feb 2014 19:12:55 +0000

Perhaps one thing TRAM signaling can return to the client is a link to an
API for doing QoS control.

Then whatever QoS control protocol you want to use could be patched in.

Might make this a little more future proof.

Michael Hammer

Principal Engineer

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

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

From: tram [mailto:[email-masked]] On Behalf Of Yoakum, John H (John)
Sent: Thursday, February 20, 2014 1:56 PM
To: Oleg Moskalenko; Alan Johnston
Cc: Karl Stahl; [email-masked]
Subject: Re: [tram] Fwd: I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

+1

I fully agree with the comments that QOS should be a low priority for the
initial focus of the TRAM efforts.  There are other groups doing QOS work
and frankly I engage in WebRTC multimedia interactions daily over the
Internet, enterprise VPNs, and various combinations and seldom suffer
egregious quality issues.  I am more concerned about carriers doing things
to regulate or degrade WebRTC flows than a failure of existing Internet
mechanisms to enable them.

Significant focus on QOS before we better enable TURN to be easily used in a
browser environment taking advantage or normal web characteristics (as
opposed to historic telephony constructs) would seem to be highly
distracting at this point.

Cheers,

John

AVAYA
1.919.425.8446 

Subject: Re: [tram] Fwd: I-D Action:

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <[email-masked]>
wrote:

-

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Feb 2014 14:22:07 -0500

On 2/20/14 2:12 PM, Michael Hammer wrote:
> Perhaps one thing TRAM signaling can return to the client is a link to
> an API for doing QoS control.
>

"A link to an API"?????

AFAIK that doesn't make sense.

A link that identifies a target and protocol to control QoS makes some 
sense to me. But then how do you know the client will support the 
protocol you are offering?

	Thanks,
	Paul

---

From: Oleg Moskalenko <[email-masked]>
Date: Thu, 20 Feb 2014 11:25:27 -0800

Obviously, a "link to API" means here "a URL/URI to REST API to QoS".

I am not sure that such  web-based API exist. May be, a custom proprietary
implementation can be used.

But I'd postpone any discussion on that matter.

On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <[email-masked]>wrote:

> sense to me. But then how do you know the client will support the protocol
> you are offering?
>
>         Thanks,
>         Paul
>
>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 20 Feb 2014 19:30:21 +0000

Paul,

Speaking loosely.

Meant in the same vein that architecturally, SIP, SDP, RTP, STUN, TURN, ICE,
etc.

Know how to work collectively, so you don't have to design this
monolithically into one protocol.

SDP knows how to select codecs, no?

I would hope that IETF doesn't create so many that it needs to be
negotiated.

Hope you catch my drift now.

Yes, was hoping that if architecture vision indicates how to separate these
protocols, 

then we can postpone discussion on QoS to another WG to address, if it
hasn't already.

Michael Hammer

Principal Engineer

Mobile: +1 408-202-9291

Milpitas, CA 95035 USA

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 2:25 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [tram] Fwd: I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

 

On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <[email-masked]>
wrote:

"A link to an API"?????

A link that identifies a target and protocol to control QoS makes some sense
to me. But then how do you know the client will support the protocol you are
offering?

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Feb 2014 14:35:21 -0500

> Obviously, a "link to API" means here "a URL/URI to REST API to QoS".

Maybe that is what was intended. If so - if a single REST API is meant, 
and the only variable is the target - then fine. That wasn't obvious to me.

> I am not sure that such  web-based API exist. May be, a custom
> proprietary implementation can be used.
>
> On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <[email-masked]
>     A link that identifies a target and protocol to control QoS makes
>     some sense to me. But then how do you know the client will support
>     the protocol you are offering?
>
>              Thanks,
>              Paul
>
>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 21 Feb 2014 09:37:09 +0000

Hi,

I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information.  IMHO that would be extending the STUN spec and should be within the TRAM charter.  The main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on the wire format discussions.

.-.
Pål-Erik

On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <[email-masked]<mailto:[email-masked]>> wrote:

+1

Cheers,
John

AVAYA
1.919.425.8446

From: tram [mailto:[email-masked]] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; [email-masked]<mailto:[email-masked]>
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

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

---

From: Alan Johnston <[email-masked]>
Date: Fri, 21 Feb 2014 11:58:51 -0600

I guess the way I would expect this to progress is for QoS discussions to
happen in another working group.  Once that other working group came to
consensus on an approach, and if that approach required STUN or TURN
extensions, then we would discuss mechanisms and possible milestones in
TRAM.

- Alan -

On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>  Hi,
>
>  I agree the full QoS discussion should _not_ happen in TRAM. If you are
> interested in helping out in that area I suggest you looking into the AEON
> mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are
> currently working on a problem-statement draft and a use-case draft, any
> input to those would be very helpful. (
> http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01,
> http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).
>
>  That said, STUN have a few nice characteristics that makes it a perfect
> candidate for transporting some of the QoS information.  IMHO that would be
> extending the STUN spec and should be within the TRAM charter.  The main
> goal of draft-martinsen-tram-discuss was to show how already existing QoS
> mechanisms could be transported with STUN to provide more value, and to
> start the discussion if TRAM is the appropriate place to have those on the
> wire format discussions.
>
>  .-.
> Pål-Erik
>
>
>
>
>
>
>  On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <[email-masked]>
> wrote:
>
>   +1
>  I fully agree with the comments that QOS should be a low priority for
> the initial focus of the TRAM efforts.  There are other groups doing QOS
> work and frankly I engage in WebRTC multimedia interactions daily over the
>  Significant focus on QOS before we better enable TURN to be easily used
> in a browser environment taking advantage or normal web characteristics (as
>  *John*
>  *From:* tram [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Oleg Moskalenko
> *Sent:* Thursday, February 20, 2014 12:43 PM
> *To:* Alan Johnston
> *Cc:* Karl Stahl; [email-masked]
> *Subject:* Re: [tram] Fwd: I-D Action:
>   Personally, I am not sure how much QoS is actually in scope for TRAM.
> Have you been following RMCAT where congestion avoidance for RTP is being

---

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

Hi Pål,

You did not comment nor answer, in response to any of:

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

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

whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the
application/browser to transfer relevant real-time traffic information
(types and bandwidth) into every RTP package by using the already IETF
standardized RTP extension header RCF 5285, which could be used by any
current or future Internet (including OTT) network where WebRTC real-time
traffic may flow. It seems to have been standardized already 2008 to allow
such usage.

QoS related step C) draft-martinsen-tram-discuss can then be taken out of
TRAM, and step D) (that was never intended to be handled by TRAM anyway)
will be handled elsewhere.

I have repeated my suggestion to RTCWEB WG from the October discussions on
the relevant [rtcweb] [avtext] [mmusic] lists
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to
introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage
suggesting usage of RFC 5285, where traffic information in RTP packets
simply would be filled by any browser under any OS.

Without step B), TRAM “Enforcing the real-time traffic through the
offered/discovered TURN servers”, the real-time traffic may happen through
the IP default gateways often congested by data traffic and QoS insensitive
streaming video and file sharing. Without specific QoS methods at those
points, the network raw bandwidth capacity may have to be 10-folded to
achieve sufficient QoE when WebRTC usage becomes popular. Methods like
DISCUSS addresses such things occurring when STUN instead TURN is used (by
allowing flows into such congestion points), but only provides direct
traffic info for outgoing (not incoming) real-time traffic and locally,
therefore are not even applicable to reservation type of networks like Cable
Networks and Mobile OTT. 

That would leave certain network types to investing in raw bandwidth
increase, instead of simply borrowing the bandwidth (from much larger data
traffic and QoS insensitive streaming video and file sharing at no adverse
effect) and making that borrowed no-cost bandwidth very valuable for the
carriers when delivering to their customers.

I know a few of you Cisco guys are among the ones that have been fighting
against the general “it is all about bandwidth” and “it will go away with
time”-attitude within IETF work, e.g. see
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but the
pointers given in the current QoS discussion within TRAM: 

(i) will *not allow* ISP’s to use already available and currently deployable
quality IP pipes for real-time traffic to also be used for WebRTC generated
real-time traffic.

(ii) will *not allow* some network types (e.g. Cable Networks and Mobile
OTT) to borrow bandwidth from data traffic and QoS insensitive streaming
video and file sharing. All networks will *also be inhibited* from the very
common and used method of simply providing an extra IP pipe (often provided
over the same wire but level-2 separated) dedicated for real-time usage

(*by resisting TRAM implementation of step B*)

Newer, fiber only type of networks, can still borrow bandwidth at no extra
cost, *by proprietary usage* of RFC 5285 by browsers. 

(iii) will leave most ISPs to *only use* raw bandwidth capacity increase
that may has to be 10-folded to reach sufficient QoE when WebRTC usage
becomes popular (if at all possible, since unmanaged IP pipes intermittently
are filled, whatever bandwidth is available).

Further explainations about QoS methods and their implementation were given
a few days ago in: 

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

(i), (ii) and (iii) will *seriously delay* usage of telepresence capable and
quality demanding WebRTC (bandwidth being around 30 times higher over best
effort Internet, than telephony over quality managed networks) and will
*vastly increase cost* for ISPs to offer WebRTC with good QoE.

Below you are giving pointers saying “They are currently working on a
problem-statement draft and a use-case draft, any input to those would be
very helpful.” Those are unnecessary, risking leading to (i), (ii) and (iii)
above.

So are pointers such as: “RMCAT where congestion avoidance for RTP is being
developed”. TRAMs Milestone 3 is for the purpose of directing real-time
traffic where congestion control isn’t already in place. Using RFC 5285
available since 2008, to fill traffic information in RTP packets (step D))
is probably a necessity for most future “congestion control” discussed.

This chicken-and-egg circular also applies to RTCWEB direction of QoS issues
to: 

http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos 

focusing on DSCP-mapping without even mentioning RFC 5285 available since
2008, to fill traffic information in RTP packets where it  is a necessity
and will allow: 

(1) 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* dedicated clients (not using WebRTC), under
*all* OSs, and *all* current and future IP networks 

(3) *without* having to be forced into application specific networks (PSTN,
IMS) instead of using the Internet (including OTT).

The only activity required, is to call for ISPs’ review whether the traffic
information transferred by RFC 5285 is sufficient for current and future
needs in their network as suggested in
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 the RFC in place.

With TRAM milestone 3 also place, 

market forces will drive ISPs and browser makers to implement just that,
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: tram [mailto:[email-masked]] För Pal Martinsen (palmarti)
Skickat: den 21 februari 2014 10:37
Till: [email-masked]
Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John)
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

Hi,

I agree the full QoS discussion should _not_ happen in TRAM. If you are
interested in helping out in that area I suggest you looking into the AEON
mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are
currently working on a problem-statement draft and a use-case draft, any
input to those would be very helpful.
(http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01,
http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

.-.

Pål-Erik

 

On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <[email-masked]> wrote:

+1

 

Cheers,

John

AVAYA
1.919.425.8446

 

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <
<mailto:[email-masked]> [email-masked]> wrote:

-

---

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

To the TRAM WG and RTCWEB WG and ADs:

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.)

I request that this is explicitly clarified in the TRAM charter.

The QoS discussions that has appeared in this TRAM WG, resulting from 

draft-martinsen-tram-discuss-00.txt

and 

has been confusing (to say the least), risking that the general QoS attitude
within IETF work “it is all about bandwidth” and “it will go away with
time”: 

video and file sharing. That all networks *will be inhibited* from the very

*while* newer, fiber only type of networks, still can borrow bandwidth at no
extra cost, *by proprietary usage* of RFC 5285 by browsers. 

(iii) will leave most ISPs to *only use* raw bandwidth capacity increase
that may have to be 10-folded to reach sufficient QoE when WebRTC usage
becomes popular (if at all possible, since unmanaged IP pipes intermittently
are filled, whatever bandwidth is available).

Further explanations about QoS methods and their implementation were given a
few days ago in: 

(i), (ii) and (iii) risk *seriously delaying* usage of telepresence capable
and quality demanding WebRTC (bandwidth being around 30 times higher over
best effort Internet, than telephony over quality managed networks) and will
*vastly increase cost* for ISPs to offer WebRTC with good QoE.

I am therefore advising that draft-martinsen-tram-discuss-00.txt and
draft-thomson-tram-turn-bandwidth-00.txt 

are withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt can be
reintroduced after clarification in the draft, that it is not about QoS as
clarified by
http://www.ietf.org/mail-archive/web/tram/current/msg00276.html.

There are further details about this in the email
http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also copied
below.

It is therein explained that my repeated suggestion to RTCWEB WG
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html from the
October discussions on the relevant [rtcweb] [avtext] [mmusic] lists
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to
introduce the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage
in combinations with the Milestone 3 objectives of TRAM, immediately would
allow:

(1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in
addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to
quickly allow us to finally enjoy the high quality and connectivity
(NAT/firewall traversal) of real-time communication services now possible,
for  

(3) *without* having to be forced into application specific networks (PSTN,
IMS) instead of the Internet (including OTT).

The only activity required, is to call for ISPs’ review whether the traffic
information transferred by RFC 5285 is sufficient for the needs of their
networks.

WebRTC *can be* used for existing application specific IP networks (such as
IMS) for services existing on these networks, but with the introduction of
the TRAM objectives above and the proposed traffic information in every RTP
packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html as
made possible by RFC 5285 available since 2008: 

(a) the same as well as other real-time services using IETF RTP traffic,
*can also (often much better) be* implemented over the Internet (including
OTT)

(b) also considering needs of QoS, media routing, control, quality
measurements, SLA implementation, usage, accounting, billing and SP-peering,

that so far has been attributed application specific networks, but in
practice and in reality have shown difficulties to implement (e.g. SP’s
peering of beyond POTS services, resulting in that the 50 year old, pre-AM
radio quality telephony service, still is the only truly global
communication service (and today often is used to initiate other better
proprietary communication services).

Application specific networks such as the IMS network have their own methods
of handling QoS, that not in anyway will be made less efficient by the
methods proposed here. Application specific networks *can use and will also
benefit* from the flow control and traffic requirement marking of RTP
streams proposed here.

WebRTC *will be* used over the Internet (including OTT) and *will probably
also be* used over the application specific IMS network for the services
existing there through a gateway function from the Internet. 

With RFC 5285 QoS usage and with TRAM milestone 3 in place (which I suggest
the WGs to expedite), 

The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF
standard work in these WGs by contributors having an interest in more than
one of current or emerging: ISPs, carrier equipment vendors or web browser
makers, may discriminate any with an interest only in one of these. The same
should apply to non-activity by WG contributors to remedy such
discrimination opened by allowed proprietary usage of RFCs such as RFC 5285.

One input for such review are responses directed to me in the September –
October discussion on the RTCWEB list and on the TRAM list from my entry
there February 8
http://www.ietf.org/mail-archive/web/tram/current/msg00132.html.

Please see just sent emails:

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

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

and further emails soon following this one, for details and history.

/Karl  

Charter charter-ietf-tram-01
<https://datatracker.ietf.org/doc/charter-ietf-tram/>
https://datatracker.ietf.org/doc/charter-ietf-tram/ 

Från: Karl Stahl [mailto:[email-masked]] 
Skickat: den 24 februari 2014 23:22
Till: 'Pal Martinsen (palmarti)'; [email-masked]'; [email-masked]'
Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; 'Yoakum, John H (John)'
Ämne: SV: [tram] [rtcweb] I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

Hi Pål,

Further explanations about QoS methods and their implementation were given a
few days ago in: 

<snip>

</snip>

/Karl

Från: Pal Martinsen (palmarti) [mailto:[email-masked]] 
Skickat: den 21 februari 2014 10:37
Till: [email-masked]
Kopia: Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H (John)
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

Hi,

.-.

Pål-Erik

On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <
<mailto:[email-masked]> [email-masked]> wrote:

+1

 

Cheers,

John

AVAYA
1.919.425.8446

 

 

-

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 25 Feb 2014 12:48:06 +0000

On 24 Feb 2014, at 23:22 pm, Karl Stahl <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pål,

Sorry about that. I did not notice any clear items to answer or comment on.

whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC real-time traffic may flow. It seems to have been standardized already 2008 to allow such usage.

draft-martinsen-tram-discuss is intended to solve internal application stream prioritisation pr flow, i.e. it is more important for me to get the video stream across than my application stream at this moment in time. Its intention is to describe the 5-topple the STUN message was sent on.

Moving to a pr packet prioritisation is interesting as it can solve the bundle problem, and mark the relative importance of specific video frames (I-Frames for example). Since its pr packet the network element might not keep stream state so it might be easier that way. But the information needs to be in a fixed offset for quick network element processing. And we want to describe other streams than just RTP. That makes RTP header extensions unsuitable.

QoS related step C) draft-martinsen-tram-discuss can then be taken out of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere.

I was hoping to argue that the draft is only new signalling of old concepts (DSCP and ECN). In the end it is the WG that decides if there is enough interest.

I have repeated my suggestion to RTCWEB WG from the October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS.

Without step B), TRAM “Enforcing the real-time traffic through the offered/discovered TURN servers”, the real-time traffic may happen through the IP default gateways often congested by data traffic and QoS insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like Cable Networks and Mobile OTT.

If both clients supports draft-martinsen-tram-discuss you would get an bi-directional end to end description of the flow that works through NAT.
The information in the STUN packet can be used to remark DSCP bits to whatever values that is of best use for the network the packet is flowing though.

I dont see how TURN gives that ability. Once the channel is bound you only have a channel number in front of the UDP payload. And TURN is designed to carry alls sort of traffic. For this to work there must be some sort of only webRTC traffic is allowed through this TURN server. (And Ill bet bitorrent or others find a way to mimic webRTC to set up only a data channel..)

That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger data traffic and QoS insensitive streaming video and file sharing at no adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers.
I know a few of you Cisco guys are among the ones that have been fighting against the general “it is all about bandwidth” and “it will go away with time”-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but the pointers given in the current QoS discussion within TRAM:

(i) will *not allow* ISP’s to use already available and currently deployable quality IP pipes for real-time traffic to also be used for WebRTC generated real-time traffic.

(ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the very common and used method of simply providing an extra IP pipe (often provided over the same wire but level-2 separated) dedicated for real-time usage
(*by resisting TRAM implementation of step B*)
Newer, fiber only type of networks, can still borrow bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by browsers.

(iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whatever bandwidth is available).

Further explainations about QoS methods and their implementation were given a few days ago in:
http://www.ietf.org/mail-archive/web/tram/current/msg00274.html

(i), (ii) and (iii) will *seriously delay* usage of telepresence capable and quality demanding WebRTC (bandwidth being around 30 times higher over best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE.

Below you are giving pointers saying “They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful.” Those are unnecessary, risking leading to (i), (ii) and (iii) above.

We find them quite useful. It allows us to engage with potential users and see if there are real problems to solve. If the customer/users do not see a problem there is little incentive for us to invest in creating a solution that nobody wants. That said, it is always the danger of crating a to complicated solution that solves to many problems.

So are pointers such as: “RMCAT where congestion avoidance for RTP is being developed”. TRAMs Milestone 3 is for the purpose of directing real-time traffic where congestion control isn’t already in place. UsingRFC 5285 available since 2008, to fill traffic information in RTP packets (step D)) is probably a necessity for most future “congestion control” discussed.

There are some good example of RTP header extension usage. For example draft-avtext-berger-framemarking. But that information may very well be encrypted and unavailable to the network element.

.-.
Pål-Erik

This chicken-and-egg circular also applies to RTCWEB direction of QoS issues to:
http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos
focusing on DSCP-mapping without even mentioning RFC 5285 available since 2008, to fill traffic information in RTP packets where it  is a necessity and will allow:
(1) 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* dedicated clients (not using WebRTC), under *all* OSs, and *all* current and future IP networks
(3) *without* having to be forced into application specific networks (PSTN, IMS) instead of using the Internet (including OTT).

The only activity required, is to call for ISPs’ review whether the traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in 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 the RFC in place.
With TRAM milestone 3 also place,
market forces will drive ISPs and browser makers to implement just that, 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.
 l
Please see further emails soon following this one, for details and history.

/Karl

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

Hi,

.-.
Pål-Erik

+1

Cheers,
John

AVAYA
1.919.425.8446

---

From: "Karl Stahl" <[email-masked]>
Date: Tue, 25 Feb 2014 01:20:30 +0100

Hi Alan,

I have in previous email
http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested
that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken off
the TRAM WG, but I think is shall be reintroduced after you clarify as you
do in 

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

Hi Karl, Thanks for your comments and feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS.  It
is about fairness between users of a TURN server, and a TURN server being
able to indicate rate limiting policy to users. in the draft.

The “confusion” (to say least, see below) surrounding QoS within IETF has
lead me to protest and address the TRAM WG and RTCWEB WG and ADs with the
advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.html :

“The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF
standard work in these WGs by contributors having an interest in more than
one of current or emerging: ISPs, carrier equipment vendors or web browser
makers, may discriminate any with an interest only in one of these. The same
should apply to non-activity by WG contributors to remedy such
discrimination opened by allowed proprietary usage of RFCs such as RFC
5285.” 

This is because the introduction of the QoS related usage of RFC 5285 into
draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives
of TRAM, immediately would allow for:

While the “confusion” surrounding the QoS discussion in TRAM and RTCWEB
combined with the general QoS attitude within IETF “it is all about
bandwidth” and “it will go away with time” otherwise:

As Good doers, we should not allow this to happen.

/Karl

Från: Alan Johnston [mailto:[email-masked]] 
Skickat: den 21 februari 2014 18:59
Till: Pal Martinsen (palmarti)
Kopia: [email-masked]; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John)
Ämne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

- Alan -

On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti)
<[email-masked]> wrote:

Hi,

.-.

Pål-Erik

+1

 

Cheers,

John

AVAYA
1.919.425.8446

 

 

-

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 25 Feb 2014 11:35:26 -0600

Dear TRAMsters,

If I might offer a couple of suggestions to a new working group ...

The TSV area diverts QoS discussions to the TSVWG working group, because 
that's where the QoS DSCP expertise lives.

RTCWeb and TSVWG are having a robust and so-far productive discussion 
about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs 
for both working groups"). That discussion is more likely to be 
productive if RTCWeb QoS topics don't start popping up on other working 
group mailing lists, like this one.

I'll let your working group chairs actually run the working group, but I 
note as more than an interested observer that the TRAM agenda at 
https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, 
and I would really be happier if the working group focuses on the 
currently chartered milestones and demonstrates that you can deliver 
what you're already signed up to deliver, before adding more milestones. 
The rest of the IESG would be happier as well.

Thanks, and see you in London.

Spencer, as your responsible AD

---

From: Justin Uberti <[email-masked]>
Date: Tue, 25 Feb 2014 09:36:28 -0800

+1, let us not try to solve problems we are not chartered to solve

On Tue, Feb 25, 2014 at 9:35 AM, Spencer Dawkins <
[email-masked]> wrote:

> about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs for
> both working groups"). That discussion is more likely to be productive if
> RTCWeb QoS topics don't start popping up on other working group mailing
> lists, like this one.
>
> https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and
> I would really be happier if the working group focuses on the currently
> chartered milestones and demonstrates that you can deliver what you're
> already signed up to deliver, before adding more milestones. The rest of
> the IESG would be happier as well.
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 25 Feb 2014 11:59:38 -0600

It would also be extremely helpful in cases where it's not entirely clear
whether the discussion belongs in TRAM, RTCWEB, etc. to please avoid
cross-posting.  Please check with the chairs about what list they think is
most appropriate and then just send a note to other lists that might care
that the discussion is happening on a specific mailing list.  It's
extremely confusing for those of us on multiple lists that try to sort and
follow threads by working groups.

---

From: James Polk <[email-masked]>
Date: Tue, 25 Feb 2014 14:44:32 -0600

But that didn't happen here. Only Certain ADs and 
certain WG chairs were cc'd. You surely don't have a problem with that...?

James

At 11:59 AM 2/25/2014, Mary Barnes wrote:
>It would also be extremely helpful in cases 
>where it's not entirely clear whether the 
>discussion belongs in TRAM, RTCWEB, etc. to 
>please avoid cross-posting.  Please check with 
>the chairs about what list they think is most 
>appropriate and then just send a note to other 
>lists that might care that the discussion is 
>happening on a specific mailing list.  It's 
>extremely confusing for those of us on multiple 
>lists that try to sort and follow threads by working groups.
>
>
>On Tue, Feb 25, 2014 at 11:35 AM, Spencer 
>Dawkins 
><<mailto:[email-masked]>[email-masked]> wrote:
>Dear TRAMsters,
>
>The TSV area diverts QoS discussions to the 
>TSVWG working group, because that's where the QoS DSCP expertise lives.
>
>RTCWeb and TSVWG are having a robust and so-far 
>productive discussion about QoS for RTCWeb now 
>(by "robust", I mean "involving chairs and ADs 
>for both working groups"). That discussion is 
>more likely to be productive if RTCWeb QoS 
>topics don't start popping up on other working 
>I'll let your working group chairs actually run 
>the working group, but I note as more than an 
>interested observer that the TRAM agenda at 
><https://datatracker.ietf.org/meeting/89/agenda/tram/>https://datatracker.ietf.org/meeting/89/agenda/tram/ 
>is really tight, and I would really be happier 
>if the working group focuses on the currently 
>chartered milestones and demonstrates that you 
>can deliver what you're already signed up to 
>deliver, before adding more milestones. The rest 
>of the IESG would be happier as well.
>
><http://tools.ietf.org/search/rfc5766#section-12>http://tools.ietf.org/search/rfc5766#section-12
>
><mailto:[email-masked]>[email-masked]

---

From: Mary Barnes <[email-masked]>
Date: Tue, 25 Feb 2014 15:28:54 -0600

James,

Correct. This current email thread was not cross posted but it was posted
to the TRAM mailing list and not just some WG chairs as you noted. My point
was that one of the threads of discussion which triggered this email
involved cross posting.   For some of us that are subscribed to all the
lists involved, it gets crazy trying to follow these threads.

Mary.

On Tue, Feb 25, 2014 at 2:44 PM, James Polk <[email-masked]> wrote:

> But that didn't happen here. Only Certain ADs and certain WG chairs were
> cc'd. You surely don't have a problem with that...?
>
> James
>
>
>> On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins <<mailto:
>> [email-masked]>[email-masked]> wrote:
>> Dear TRAMsters,
>>
>> note as more than an interested observer that the TRAM agenda at <
>> https://datatracker.ietf.org/meeting/89/agenda/tram/>https:
>> //datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and I
>> would really be happier if the working group focuses on the currently

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 01:05:38 +0000

On Feb 25, 2014, at 7:02 AM, Karl Stahl <[email-masked]> wrote:

> 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.
>  

Reading the charter, the above is *not* at all a clear objective of the WG (note I am not the chair of this WG or the responsible AD). 

That said, I think you have pointed out this charter is abysmally vague - it does not say what the WG is not going to do. If I decided to do BGP for routing updates over TURN it would be within the scope of this charter. 

My advice to the responsible AD is recharter this WG before IETF 90 or close it. I would be glad to help write a charter that is not an infinite blank cheque.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 01:08:08 +0000

resend because the IETF mail lists said I had to many people in the to line

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 01:08:09 +0000

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 00:49:18 +0000

Karl, 

I am totally lost on this thread. Could you start a new tmead that summarize what the issues is, what seems to be the point of debate, and what your view is on what we should do. I think that would help make progress. 

Thank you, 

Cullen 

On Feb 25, 2014, at 8:20 AM, Karl Stahl <[email-masked]> wrote:

> Hi Alan,
>  
> I have in previous email http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken off the TRAM WG, but I think is shall be reintroduced after you clarify as you do in
> You are correct in saying that the BANDWIDTH extension is not about QoS.  It is about fairness between users of a TURN server, and a TURN server being able to indicate rate limiting policy to users. in the draft.
>  
> The “confusion” (to say least, see below) surrounding QoS within IETF has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with the advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.html :
> “The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether IETF standard work in these WGs by contributors having an interest in more than one of current or emerging: ISPs, carrier equipment vendors or web browser makers, may discriminate any with an interest only in one of these. The same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC 5285.”
>  
> This is because the introduction of the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives of TRAM, immediately would allow for:
> (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now possible, for  
> (3) *without* having to be forced into application specific networks (PSTN, IMS) instead of the Internet (including OTT).
>  
> While the “confusion” surrounding the QoS discussion in TRAM and RTCWEB combined with thegeneral QoS attitude within IETF “it is all about bandwidth” and “it will go away with time” otherwise:
> (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the very common and used method of simply providing an extra IP pipe (often provided over the same wire but level-2 separated) dedicated for real-time usage
> *while* newer, fiber only type of networks, still can borrow bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by browsers.
> (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whatever bandwidth is available).
>  
> I guess the way I would expect this to progress is for QoS discussions to happen in another working group.  Once that other working group came to consensus on an approach, and if that approach required STUN or TURN extensions, then we would discuss mechanisms and possible milestones in TRAM.
>  
> - Alan -
>  
> 
> On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:
> Hi,
>  
> On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <[email-masked]> wrote:
>  
>  
>  
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Feb 2014 17:12:20 -0800

> That said, I think you have pointed out this charter is abysmally
> vague - it does not say what the WG is not going to do. If I
> decided to do BGP for routing updates over TURN it would be
> within the scope of this charter.

Cullen, is it your opinion that a working group is always free to do
anything that's not explicitly forbidden in its charter?

I think that a working group is limited to doing what *is* in its
charter, and we sometimes explicitly forbid things for emphasis.

The TRAM charter says this:

   The work will include the addition of DTLS
   as an additional transport, authentication mechanisms, and
   extensions to TURN and STUN.

I don't think that would support, for example, BGP over TURN.

Barry

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 25 Feb 2014 20:52:39 -0600

So ... TRAM was chartered last Thursday ...

I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG 
Chair) and Simon actually chair their working group for at least a full 
week before intruding further, but for now, let's assume that the 
working group wants to work on the milestones they signed up for last 
week, and see how badly that assumption blows up, rather than talk about 
rechartering every time someone proposes a topic that's out of scope.

I look forward to attending the first working group session next week, 
and to balloting on six TRAM drafts before IETF 92.

Thanks,

Spencer, as the responsible AD

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 08:05:30 +0000

> I don't think that would support, for example, BGP over TURN.

BGP over TURN sounds like a turn extension to me. Now you might think that is a silly one and I would agree but I assure you Karl does not think the QoS extensions are silly extensions to TURN. 

So in your opinion are they in scope or out, I think that is the heart of the issue right now. I’m of the opinion they are in scope so I look forward to agenda time be allocated for them. 

Cullen

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 26 Feb 2014 08:26:13 +0000

On Feb 26, 2014, at 10:52 AM, Spencer Dawkins <[email-masked]> wrote:

> I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Chair) and Simon actually chair their working group for at least a full week before intruding further, but for now, let's assume that the working group wants to work on the milestones they signed up for last week, and see how badly that assumption blows up, rather than talk about rechartering every time someone proposes a topic that's out of scope.
> 
> I look forward to attending the first working group session next week, and to balloting on six TRAM drafts before IETF 92.
> 
> Thanks,
> 

Makes sense - I get the desire to let some work get done. 

I worry that every time someone says something is is not in scope of this WG, it is not going to feel like an open consensus decisions but is instead going to feel like a arbitrary fiat decisions by a chair or IESG made in a dark and smoky room - I hope I am wrong.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Feb 2014 08:11:01 -0500

Thanks, Spencer.

Please everyone also keep in mind that there's a big difference between
what is allowed to be discussed on the mailing list, where a very
liberal view of what is "on topic" usually applies, and what actually
gets agenda time, milestones, and adopted drafts, which is handled much
more strictly.

Simon

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Feb 2014 15:46:12 +0200

Hi,

Mary is right. People should avoid cross-posting to several mailing
lists because it increases the chances of people missing messages
because of their email filters.

Cheers,

Gonzalo

On 25/02/2014 11:28 PM, Mary Barnes wrote:
> James,
> 
> Correct. This current email thread was not cross posted but it was
> posted to the TRAM mailing list and not just some WG chairs as you
> noted. My point was that one of the threads of discussion which
> triggered this email involved cross posting.   For some of us that are
> subscribed to all the lists involved, it gets crazy trying to follow
> these threads. 
> 
> Mary. 
> 
> 
> On Tue, Feb 25, 2014 at 2:44 PM, James Polk <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     But that didn't happen here. Only Certain ADs and certain WG chairs
>     were cc'd. You surely don't have a problem with that...?
> 
>     James
> 
> 
>         It would also be extremely helpful in cases where it's not
>         entirely clear whether the discussion belongs in TRAM, RTCWEB,
>         etc. to please avoid cross-posting.  Please check with the
>         chairs about what list they think is most appropriate and then
>         just send a note to other lists that might care that the
>         discussion is happening on a specific mailing list.  It's
>         extremely confusing for those of us on multiple lists that try
>         to sort and follow threads by working groups.
> 
> 
>         On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins
>         <<mailto:[email-masked]
>         <mailto:[email-masked]>>[email-masked]
>         <mailto:[email-masked]>> wrote:
>         Dear TRAMsters,
> 
>         The TSV area diverts QoS discussions to the TSVWG working group,
>         because that's where the QoS DSCP expertise lives.
> 
>         RTCWeb and TSVWG are having a robust and so-far productive
>         discussion about QoS for RTCWeb now (by "robust", I mean
>         "involving chairs and ADs for both working groups"). That
>         discussion is more likely to be productive if RTCWeb QoS topics
>         don't start popping up on other working group mailing lists,
>         like this one.
> 
>         I'll let your working group chairs actually run the working
>         group, but I note as more than an interested observer that the
>         TRAM agenda at
>         <https://datatracker.ietf.org/__meeting/89/agenda/tram/
>         <https://datatracker.ietf.org/meeting/89/agenda/tram/>>https:__//datatracker.ietf.org/__meeting/89/agenda/tram/
>         <https://datatracker.ietf.org/meeting/89/agenda/tram/> is really
>         tight, and I would really be happier if the working group
>         focuses on the currently chartered milestones and demonstrates
>         that you can deliver what you're already signed up to deliver,
>         before adding more milestones. The rest of the IESG would be
>         happier as well.
> 
> 
>         <http://tools.ietf.org/search/__rfc5766#section-12
>         <http://tools.ietf.org/search/rfc5766#section-12>>http://__tools.ietf.org/search/rfc5766#__section-12
>         <http://tools.ietf.org/search/rfc5766#section-12>
> 
> 
>         <mailto:[email-masked] <mailto:[email-masked]>>[email-masked]
>         <mailto:[email-masked]>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Feb 2014 15:53:09 +0200

Hi Cullen,

I am keeping the cc: as is in order to close this thread but let's try
and avoid cross-posting in future discussions.

Thanks for your input. I agree that explicit charters are better than
implicit ones, especially around areas that can be controversial. Given
that we are not going to recharter the WG in the next few days, we are
going to focus the session in London on items that are *explicitly*
chartered.

After London, if we need to tighten the charter somehow, we will do that.

Cheers,

Gonzalo

---

From: "Karl Stahl" <[email-masked]>
Date: Wed, 26 Feb 2014 16:47:50 +0100

(After having typed this up; I see today’s charter discussion etc. that I
haven’t read yet, but it will hopefully will be clearer by pointing at this
entry.)

Hi John, and 

Collin, Pål, Magnus, Charles,  Simon,

In my step A) B) and D) efforts in
http://www.ietf.org/mail-archive/web/tram/current/msg00275.html for 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 have to be a
bit clever here :). I only see these few standard steps required, before it
can happen!”

To accomplish these (1), (2), (3)-things for:

There are a lot of Mission Impossible, Pointers, Good arguments and other
things to consider in the mails from you guys that I have not (yet)
answered.

Allow me to come back to those under THIS THREAD/Subject after having
figured out how to do it in a structured way, with the aim of collecting the
summary in a new "Interfacing to QoS" thread, that only will relate to how
IP/IETF/WebRTC level 3-5 – *can interface* to the QoS-stuff (whether within
IETF, in the telephony world or elsewhere e.g. IEEE Ethernet, mainly
relating to lower level).

I think this is doable *without* ending up in any of the (i), (ii),
(iii)-things 

(?) and possible other Evil -things.

I refer to http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html
for these “-things” and further.

John, Alan, Henry (Sinnreich), Henning, Richard, Cullen, Jörgen (Björkner),
Lars (Berggren) and other good friends since the early SIP age (before SIP
was “hijacked” into application specific network and proprietary usage and
nowadays rarely is used the IETF-way): 

I want to point out how “confusing” the QoS-issue has been and as hard as I
will the fight Mission Impossible attitude, I will also fight the “it is all
about bandwidth” and “it will go away with time” attitude…  (also in the
above http reference)

I agree with parts of what John says below but the remedy to achieve the
Good (1), (2), (3)-things instead of the Evil (i), (ii), (iii)-things, is
NOT to ignore QoS-things – It is the opposite! 

For you having more and relevant input – That has not been said, and that
you think I will not address anyway – in this "Interfacing to QoS" path,
please provide, but I will not be able to process much more than already
have been said – and I will use http back-pointers for what has already been
discussed in more detail.

If you want to point out QoS-stuff Requiring More Input-from/Feedback-to the
level 3 and above stuff IN ADDITION to what already has been discussed here
http://www.ietf.org/mail-archive/web/tram/current/msg00302.html  

Please also point out WHAT and WHY that can/or cannot be handled by the
methods proposed here and whether other existing methods can be used to
achieve the mission of "Interfacing to QoS" from IP = level 3 to lower
levels.

I will do some thinking about what LISTs different things shall be brought
to and then split the [TRAM] [WEBRTC] and advice regarding involving other
list will be considered. Such will probably show up and happen during this
mission.

Another thing from
http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: What name 

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).*

And Henry, I will have to continue to use the S(BC)-word and the I(MS)-word,
since you did not succeed to “eradicate” them ;-)  Let’s hope we find a word
for the above box (quite undefined on the QoS-side – It is only the TURN
side and traffic info we are up to designing here) that does not need to be
“eradicated”. So no WebRTC-SBC I guess (hopefully it will not even be
WebRTC-specific), and ICE-SBC sounds crazy (since ICE was developed to
remove the need of SIP SBCs), the same applies to TURN-SBC (which implies
that this box hopefully is not even ICE-specific). TURN-QoS-Interface box is
relevant but long… 

/Karl

PS: To avoid being stopped by the “to many recipients” spam filter, the Guys
(including Mary) from 

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

and the ones mentioned in the email are copied separately.

Från: Yoakum, John H (John) [mailto:[email-masked]] 
Skickat: den 20 februari 2014 19:56
Till: Oleg Moskalenko; Alan Johnston
Kopia: Karl Stahl; [email-masked]
Ämne: RE: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

+1

Cheers,

John

AVAYA
1.919.425.8446

---

From: Simon Perreault <[email-masked]>
Date: Wed, 26 Feb 2014 11:02:05 -0500

Karl,

It has been made clear that QoS discussion is out of scope for TRAM.
This thread has ended. If you continue posting on this topic, we will
have to take reactive measures.

Please also refrain from cross-posting to multiple lists.

Simon