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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 03 March 2014 13:32 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EB01A013F; Mon, 3 Mar 2014 05:32:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.851
X-Spam-Level:
X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAUkKuoY9II8; Mon, 3 Mar 2014 05:32:17 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5766C1A0139; Mon, 3 Mar 2014 05:32:16 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-8b-5314845b648b
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.87.10875.B5484135; Mon, 3 Mar 2014 14:32:11 +0100 (CET)
Received: from [131.160.126.237] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Mon, 3 Mar 2014 14:32:10 +0100
Message-ID: <5314845A.2060100@ericsson.com>
Date: Mon, 3 Mar 2014 13:32:10 +0000
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Karl Stahl <karl.stahl@intertex.se>, "'Cullen Jennings (fluffy)'" <fluffy@cisco.com>, 'IESG IESG' <iesg@ietf.org>
References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <CAKhHsXGzA=ZTFGTK7ht9hQbfG70iqKrDtxrZCdQNNMzBYZCk8A@mail.gmail.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <CAKhHsXGsp6ma6Ko9op+YFRqSGM_Ex-jFo_fjz69rN0SEHfNK2A@mail.gmail.com> <CALDtMrKb3_38Rs0vaGnpEvNvTYz8YUTo89STvLJNXfkfdipDSQ@mail.gmail.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <B7FA2629-6D48-4569-BB62-56395C3EE4BC@cisco.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> <AA208926-C949-4580-B20B-DCF172D3C21B@cisco.com> <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se>
In-Reply-To: <000001cf36e4$07a8a550$16f9eff0$@stahl@intertex.se>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW50i0iwwfdTphYdk9ksZvyZyGzx rmctm8Xaf+3sFt1L/7NYNM61s/iw9gKbA7vHlN8bWT12zrrL7rFkyU8mj09b57N4rPtgHsAa xWWTkpqTWZZapG+XwJXx5vg0loK1+hWfVjxmaWC8rNrFyMkhIWAi0bHzNhOELSZx4d56ti5G Lg4hgUOMEo8m9DJCOGsYJRomLmcDqeIV0JbYuXEuUAcHB4uAisSk5mqQMJuAhcSWW/dZQGxR gSiJn1cWsEOUC0qcnPkELC4iUC7x78oBVhCbWWALo8S2z0EgtjDI/K5zyhC7nrFI9O7eCNbA KeAgsfjmMnaQXRIC4hI9jUEQvXoSU662MELY8hLNW2czg9hCQKctf9bCMoFRaBaS1bOQtMxC 0rKAkXkVI3tuYmZOernhJkZg0B/c8lt3B+OpcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwJh381PMqz3L1++LunGj8vXedYyTjzmtOij8ceYqg0V89ie/tPrEXpj7 Q7nliqG8fo936pozR6SWa/Oc+nb03NolAtPKCsXmyHg9T30R4/uUQV4sTtKyN+/G5crwVb/z mddU1fX1s9Vf/TXJ/uxKt9u95zIXbX10tlTNIILblO2FgmfQIbP1pZpKLMUZiYZazEXFiQAm 5f4ASAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/mKOc5mMB66OSEsncSpXJYtyY4rs
Cc: rtcweb@ietf.org, tram@ietf.org
Subject: Re: [rtcweb] [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Mar 2014 13:32:20 -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:
> 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:karl.stahl@intertex.se] 
> Skickat: den 3 mars 2014 10:22
> Till: 'Cullen Jennings (fluffy)'; 'IESG IESG'
> Kopia: 'Magnus Westerlund'; 'Simon Perreault'; 'Ted Hardie'; 'Gonzalo
> Camarillo'; 'rtcweb@ietf.org'.org'; 'tram@ietf.org'.org'; '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:fluffy@cisco.com]
> Skickat: den 26 februari 2014 01:49
> Till: Karl Stahl
> Kopia: Alan Johnston; rtcweb@ietf.org; tram@ietf.org; 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:fluffy@cisco.com] 
> Skickat: den 26 februari 2014 02:06
> Till: Karl Stahl; IESG IESG
> Kopia: Magnus Westerlund; Simon Perreault; Ted Hardie; Gonzalo Camarillo;
> rtcweb@ietf.org; tram@ietf.org; 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 <karl.stahl@intertex.se> 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
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>