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

[Gonzalo Camarillo <[e-mail]>]

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:
> 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:[e-mail]] 
> Skickat: den 3 mars 2014 10:22
> Till: 'Cullen Jennings (fluffy)'; 'IESG IESG'
> Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo
> Camarillo'; '[e-mail]'; '[e-mail]'; '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,
> 
> 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. 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>