Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs

From: "Karl Stahl" <[email-masked]>
Date: Mon, 3 Mar 2014 10:22:12 +0100

Hi Cullen,

Memory may be an illusion, still I cannot understand how there can be an
ever growing archive in the IETF

/Karl

Allt väl
Hi Cullen,

Not to cause more lost in the threads (I am also) I am addressing both your
emails in one, and copy separately to the other guys in the first email. 

Further Inline -->

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

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

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Skickat: den 26 februari 2014 01:49
Till: Karl Stahl
Kopia: Alan Johnston; [email-masked]; [email-masked]; Bernard Aboba; David
Singer; Harald Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes;
Henning Schulzrinne
Ämne: Re: [rtcweb] [tram] I-D Action:
draft-thomson-tram-turn-bandwidth-00.txt

> 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

I just did something like that in:
[tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5
IP/IETF/WebRTC-thing how to interface to lower level's QoS-stuff 
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html 
Hoping this thread subject amplifies what this SHOULD be about. (An how it
will lead to the summary, after all diversion.)

Actually, the outcome of "Interfacing to QoS" will be 

I challenge anyone that this will be outcome, and will start "Interfacing to
QoS" with what IP "Interfacing to QoS" that we have the tiny ADSL modem IX78
that implements such CLEAR INTERFACE and the actual QoS methods, for both
the Congestion, Default gateway, Surf Pipe 
Manipulating the RTP extension header etc etc on 6 USD CPU and also include
the ADSL part where that quality handling is based on heavy 57 bytes
chopping up
   at this exact 

-----Ursprungligt meddelande-----
Från: Cullen Jennings (fluffy) [mailto:[email-masked]] 
Skickat: den 26 februari 2014 02:06
Till: Karl Stahl; IESG IESG
Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo;
[email-masked]; [email-masked]; Spencer Dawkins
Ämne: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter
Clarification regardig Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

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

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

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: "Karl Stahl" <[email-masked]>
Date: Mon, 3 Mar 2014 14:25:22 +0100

Cullen,

Illution
I am checking the IETF archive for links - Memory you know...
I feel I also have an email from Harald to answer

You will not see the below
/Kalle
Allt väl
-----Ursprungligt meddelande-----
Från: Karl Stahl [mailto:[email-masked]] 
Skickat: den 3 mars 2014 10:22
Till: 'Cullen Jennings (fluffy)'; 'IESG IESG'
Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo
Camarillo'; [email-masked]'; [email-masked]'; 'Spencer Dawkins'
Ämne: SV: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter
Clarification regardig Milestone 3: TURN server auto-discovery mechanism for
enterprise and ISPs

Hi Cullen,

/Karl

Allt väl
Hi Cullen,

Further Inline -->

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 3 Mar 2014 13:32:10 +0000

Karl,

speaking as RAI AD and TRAM WG chair:

note that our policy is to avoid cross-posting to several mailing lists.
The reason is that doing so may make it more difficult for people who
are subscribed to several lists to follow the discussions. Also,
messages with too many requirements are moderated and need to be
manually approved by the admins of each list.

Therefore, from now on, please choose only *one* mailing list;
preferably one where the discussions you intend to have are within its
scope.

Thanks,

Gonzalo

On 03/03/2014 1:25 PM, Karl Stahl wrote:
> 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
> So, in answer to Simon Perreault [simon.perreault at viagenie.ca]'s question
> ISP/NSP referred to, may represent 50%(?) of the universe's IP accesses! And
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

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

Hi Cullen,

You may first want to read the previous email to Harald: 

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

> 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

I already February 26 started a new thread for the “mission to bring quality
to real-time traffic over our best effort Internet”
<http://www.ietf.org/mail-archive/web/tram/current/msg00331.html>
http://www.ietf.org/mail-archive/web/tram/current/msg00331.html

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

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

I actually thought it was you (Cullen) that at least initiated tram
Milestone 3 with Subject: “TURN server auto-discovery mechanism for
enterprise and ISPs” [2]

After your request
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09007.html 

[Karl, I, had said]“> I've heard several carries expressing that they want
to provide their own TURN servers with their accesses.

[Cullen asked] Any chance you could put me in touch with some of them. I'd
love to get more information on what is needed so we can solve this.“

The “ huge European carrier and the cable operators in general – CableLabs”
that I refer to in
http://www.ietf.org/mail-archive/web/tram/current/msg00275.html  were the
ones I put you in touch with, and then China Mobile reached out for getting
the auto-discovery mechanism in place: “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.“

Whoever you left this to, it somehow appeared as [tram] Milestone 3. [2]

The complete Anycast method for auto discovery of ISP’s TURN servers was
suggested October 22 (without further discussions)

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

and thereafter brought into [tram] Milestone 3 by me February 8 

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

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

So referring to
http://www.ietf.org/mail-archive/web/tram/current/msg00275.html, step A) is
for the TRAM WG  to allow ISPs/NSPs to route quality demanding WebRTC media
into their IP pipes that are capable of transporting real-time traffic,
using TURN servers. Step B), how the WebRTC browser shall use the auto
discovered TURN server, which I suggested in 

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

WEB BROWSER BEHAVIOUR:

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

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

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

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

4) TURN server address being supplied by the web application

may be for the RTCWEB WG rather than TRAM WG to handle. Further I would
guess step D) is an AVTEXT WG thing – What do you think?

/Karl

Footnotes:

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

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

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.

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

Från: Cullen Jennings (fluffy) [ <mailto:[email-masked]>
mailto:[email-masked]]

Till: Karl Stahl

Kopia: Alan Johnston;  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked]; Bernard Aboba; David Singer; Harald
Tveit Alvestrand; Marc Robins; Eric Burger; Mary Barnes; Henning Schulzrinne

 

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

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

 

   at this exact 

 

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

Från: Cullen Jennings (fluffy) [ <mailto:[email-masked]>
mailto:[email-masked]] 

Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo;
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked]; Spencer Dawkins

---

From: "Karl Stahl" <[email-masked]>
Date: Thu, 13 Mar 2014 09:26:49 +0100

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

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

*SUMMARY* to be brought into the common "Interfacing to QoS"-thread

(From there it will be clearer how to split “Interfacing to QoS” into
[tram], [rtcweb] and [avtext]-threads.)

The steps A), B) to D) for achieving the mission:

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

a: Step D) using the RTP extension header RCF5285 (that works for all IP
network types) can obsolete step C) (Using STUN-attributes which is an
incomplete transfer of traffic info to the network level.) We need traffic
info (bandwidth and type) that is unchanged through various networks and can
be read and used by network elements (here in a TURN-server flow) and for
traffic in both directions.

b: Here it is only discussed for RTP (not for the data channel), but it
could be good to also consider this for the webrtc data channel. I will
discuss that in next email responding to Magnus’
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming
soon.

c: How to find and pick out the traffic information from the RTP extension
header when RCF 5285 is used for this purpose is trivial, especially when
“in-band” in a known TURN-flow. 

There are further detail in-line below for Pål, Colin, Magnus and other
interested.

/Karl

Footnotes:

[2] Here it is about recreation of the idea/intention of the RTP payload
type (PT) header that is not available for the network level anymore, by
instead having the application/browser filling the RTP header extension with
relevant traffic info that all IP network types can use. There will be more
detail in the response to Magnus’
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11549.html coming
soon.

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

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

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/msg00275.html

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

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

[Karl -regarding “Interfacing to QoS”] From what you answer below, I
conclude:

a: step D) (that works for all IP network types) can obsolete step C) (using
STUN-attributes which is an incomplete transfer of traffic info to the
network level) (We need a quality marking that is unchanged and can be read
and used throughout various networks and for traffic in both directions).

b: here it is only discussed for RTP (not for the data channel, but I will
discuss that in next email responding to Magnus.

c: you have hesitations how to find and pick out the traffic information
from the RTP extension header when RCF5285 is used for this purpose, but
that is trivial, especially when “in-band” in a known TURN-flow. See further
below.

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

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.

[Pål] 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.

[Pål] 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>
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 RFC5285, 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.

[Pål] 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.

[Karl] Again, this is only applicable for all-diffserve networks and you
cannot even route the flow to a quality pipe, not even a duplicate pipe that
is not the default gateway surf pipe (which is a very common method used for
VoIP).

[Pål] I dont see how TURN gives that ability. 

[Karl - ???] Haven’t we many times agreed that you can add exactly the same
STUN-attributes to the TURN allocate request AND in addition to that,
control where the flow goes?

BUT THIS IS ALSO INSUFFICIENT. 

I discarded such (similar) interface to QoS already October 22

 <http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html>
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html 

…

PS Microsoft seems to have done work in this field, defining a proprietary
attribute “MS Service Quality”; 

However that seems to apply to the TURN server allocation request and would
therefore:

--- Apply to the whole UDP flow, and could not be set for each stream
individually (with different requirements), and

--- Does not handle the bandwidth requirement for incoming real-time traffic
(required to reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may  be
considered.

This is 2.2.2.19 MS-Service Quality Attribute from 

 <http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx>
http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx 

…

[Pål] 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..)

[Karl] I owe Simon a response to misuse of prioritized channels – will do
later after first collecting these diversions. This has nothing to do with
STUN vs TURN! TURN just gives the addition of ALSO directing the flow. In
both cases it is insufficient to transfer traffic info in the STUN/TURN
attributes.

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

[Pål] 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.  

[Karl] This is QoS stuff. Let’s stick to “Interfacing to QoS” and with a
general interface, that the “QoS device including the TURN server” should be
able to do whatever network QoS-method you arrive at.

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 RFC5285
available since 2008, to fill traffic information in RTP packets (step D))
is probably a necessity for most future “congestion control” discussed.

[Pål] 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.

[Karl] You (Pål), Colin and Magnus seem to worry about trivial things when
using the RTP header extension, for transferring traffic information from
the application (here browser) to the network level. Don’t worry! J  These
are really trivial things :

- If we select to use the RTP extension header RCF5285 for this purpose, it
should of course NOT use RFC6904 encryption, since it is meant for network
level reading/usage!

- Finding the RTP header extension (especially when “in-band” in a known
TURN-flow) is really trivial.  

Linking each RTP-flow by its SSRC and sequence number, and picking exactly
the right traffic type and bandwidth parameters is no problem (I am not
aware of any “Zero CPU” DPI device that needs to be considered – But if we
can ease the job, we should.)

This link shows much more advanced things are available in Cisco devices: 

http://www.cisco.com/en/US/products/ps6616/products_white_paper09186a0080110
040.shtml#wp39132 

and the ADSL 2+ modem doing a lot of advanced QoS-stuff, described in 

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

is our Intertex/Ingate IX78, just powered by a 6 USD 264 MHz ARM ADSL chip
set CPU and we have implemented a check box TO REMOVE the RTP Header
extension (for the ugly reason that the ITSP’s billing system requires G.711
VoIP packets of a certain length) – It does not take noticeable CPU power to
do this at 100 Mbps wire speed! 

/Karl 

.-.

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

Från: tram [ <mailto:[email-masked]> 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>
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-use-cases-01,
<http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00>
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