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

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:[e-mail]] 
Skickat: den 26 februari 2014 01:49
Till: Karl Stahl
Kopia: Alan Johnston; [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 
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]] 
Skickat: den 26 februari 2014 02:06
Till: Karl Stahl; IESG IESG
Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo;
[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 <[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.