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

["Karl Stahl" <[e-mail]>]

Hi Cullen,

 

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

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

 

Regarding your request from February 26:
> 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 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] 

 

And from your email February 25 below:

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

 

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:[e-mail]>
mailto:[e-mail]]

Skickat: den 26 februari 2014 01:49

Till: Karl Stahl

Kopia: Alan Johnston;  <mailto:[e-mail]> [e-mail];
<mailto:[e-mail]> [e-mail]; 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>
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:[e-mail]>
mailto:[e-mail]] 

Skickat: den 26 februari 2014 02:06

Till: Karl Stahl; IESG IESG

Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo;
<mailto:[e-mail]> [e-mail];  <mailto:[e-mail]>
[e-mail]; 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 < <mailto:[e-mail]>
[e-mail]> 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.