Re: [rtcweb] Alternative consensus and MTI video codecs
Ron <ron@debian.org> Fri, 08 November 2013 12:31 UTC
Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7A21E80BE for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 04:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.212
X-Spam-Level:
X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epKNLPvCDcZO for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 04:31:16 -0800 (PST)
Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA421E80BB for <rtcweb@ietf.org>; Fri, 8 Nov 2013 04:31:14 -0800 (PST)
Received: from ppp121-45-83-213.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.83.213]) by ipmail07.adl2.internode.on.net with ESMTP; 08 Nov 2013 23:01:13 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 4CB9B4F8F3 for <rtcweb@ietf.org>; Fri, 8 Nov 2013 23:01:10 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CO2EqE4+m9IM for <rtcweb@ietf.org>; Fri, 8 Nov 2013 23:01:09 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 4B9724F902; Fri, 8 Nov 2013 23:01:09 +1030 (CST)
Date: Fri, 08 Nov 2013 23:01:09 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131108123109.GF3245@audi.shelbyville.oz>
References: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com> <527C38FF.6040000@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <527C38FF.6040000@nostrum.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] Alternative consensus and MTI video codecs
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 12:31:21 -0000
On Thu, Nov 07, 2013 at 05:06:07PM -0800, Adam Roach wrote: > On 11/7/13 16:41, Gregory Maxwell wrote: > >If we still believe from an engineering perspective that WebRTC ought > >to have one MTI video codec it still can, even though the counts were > >split: We can invoke RFC 3929 4.4 and_flip a coin_. > > I do not believe the decision under consideration qualifies for the > process in section 4.4. As that section itself notes, random > selection is only appropriate for something like deciding a > numerical codepoint or a DNS prefix. I agree that there are still too many unanswered objections to declare that both options have equal merit and a random selection of either will therefore suffice. Though I do also agree with Greg's analysis that if this group is going to punt that decision to an outside actor, we will be faced with some difficulty in finding a more unbiased selector. > Our situation is radically different: there are a number of actual > arguments to be made for both options. Yes, there certainly are. And I think our next step needs to be to distill those to the ones that are actually still contentious, and strive to achieve rough consensus on each of those remaining arguments. We already have violent agreement occurring on quite a number of the original selection points. I think we can safely say there is rough consensus on things like "the performance and quality difference is negligible enough that it isn't a deciding factor". Which means we only need to decide on the actually relevant problems that remain outside of that to see if a clear best choice remains. And I really do think that if we take each of those individually and in isolation, that each of them individually and in isolation does have an answer that we can achieve rough consensus on. And that when we then sum the result of those consensus decisions, a clear advantage will remain for just one choice. A large part of the confusion at present appears to be that whenever the Hard Questions are raised, someone then buries achieving any conclusion to them under "what about this other idea that we discussed and dismissed two years ago!!" ... lather, rinse, repeat. It's been said here many times that the IETF does not vote. Yet people are still talking about voting, and what we had today was essentially "just a vote". If it had been conclusive, that would have been great, but it wasn't, and since nobody was required to justify the reasoning for their preference vote, I think it's premature to declare "we have failed to reach rough consensus". The clear disparity between the the majority of the jabber room and the majority of the attendees is a significant piece of information in its own right, and relevant to any decision process that we might employ to establish a working rough consensus. Especially given the principle that IETF decisions are supposed to be made by consensus calls on the working group list. > I think an external review team (section 4.1) is a reasonable way > forward, as it lets the decision rest on the merits that proponents > of each approach have themselves put forth, without allowing > partisan or emotional considerations to get in the way of facts. > > I'll make an even stronger statement: I would contend that any > strong push against the use of an external review team amounts to a > tacit admission by an individual that the arguments for their > preferred position are insufficiently compelling. Superficially, and taken in isolation, that would ordinarily be a fairly compelling argument. But taken in the context of what we saw happen today, I would say that the onus is first on you to demonstrate that we _can_ select a properly neutral and unbiased review team to weigh the arguments on their actual merit. We know FOR A FACT, that there are major problems with the selection of a heavily encumbered, and restrictively licenced MTI codec. The people pushing for choosing that option have acknowledged this and tried to mitigate it by throwing several million dollars at Freebies For Some. Many people replied on the list that "this is wonderful, and we thank you a lot, but it doesn't actually solve the core problem". There was effectively no direct rebuttal to this there. And so far the only answer to those remaining problems was along the lines of "pfft, you're all just little fish, you don't matter". If the candidates for an external review team are going to inherently be biased along the same lines as the physical meeting room was, then a monte-carlo sampling of them isn't going to get us a neutral panel. And if an argument of "but the licence doesn't allow this at all", can be dismissed with "pfft, that doesn't matter", then that would seem to be a tacit admission that no argument could ever be sufficiently compelling to a group espousing that belief. > If anyone believes that their position logically follows from the > known facts, then they would necessarily believe that a > randomly-selected panel of neutral third parties will agree with > them. If such a person thinks that the panel won't, perhaps they > should reevaluate whether their arguments are grounded in facts and > logic, or their own emotional investment in this decision. My belief is that this working group hasn't actually given sufficient and complete consideration to the already known facts to set about abdicating the decision to an external group. There are serious questions raised on the list that are unanswered in any even remotely satisfactory way. Maybe people thought the show of hands today would be decisive and they would not have to answer them. But it wasn't, and so the necessity to either answer them, or admit they are the fundamental blockers that people assert they are, still remains. I think it would be impossible for this group to present this to a group of people that haven't followed the discussion to date, and expect that group to arrive at a well reasoned answer if even we don't yet have reasonable answers to questions of grave concern. We had two presentations today. One was a short and sweet "my argument remains unchanged and stands on its own merit". The other was a great modern adaptation of The Story Of The Reason. If anyone who heard it can remember what the reason actually was, I would invite them to relay it for posterity via answers to the still unanswered questions on the mailing list. Let's break this down into what the showstoppers for either choice really still are today. If we focus on that, I don't think we're actually very many steps from having a sensible decision be quite obvious and undeniable. And from having it broken down into simple things that we can achieve consensus over, step by step -- making the final step seem far less of an insurmountable leap of faith. Attempts to change things that previously had consensus is not a way forward, and we do have consensus that MTI is necessary and crap ancient codecs are not a viable option. Let's worry about what the Real problems with the two choices we have actually are and decide what needs to occur in order to resolve them if they do stand up to scrutiny as actual problems. I don't think we've actually failed at that, we've just had the argument become deeply muddled in sophistry. Having external adjudication on a final consensus may still be necessary, but that's quite different from totally punting on the work needed to establish it. Some time back Adam posted some very interesting thoughts on the mechanisms of rough consensus. I believe that if we follow those, a clear best decision will emerge. Ron
- [rtcweb] H.261 vs No MTI (was: Alternative consen… cowwoc
- [rtcweb] Alternative consensus and MTI video code… Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] Alternative consensus and MTI video … Gregory Maxwell
- Re: [rtcweb] Alternative consensus and MTI video … Ron
- Re: [rtcweb] Alternative consensus and MTI video … Adam Roach
- Re: [rtcweb] H.261 vs No MTI cowwoc
- [rtcweb] On the form of the question (was Re: Alt… Adam Roach
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI (was: Alternative co… Tim Panton
- Re: [rtcweb] H.261 vs No MTI Tim Panton
- Re: [rtcweb] H.261 vs No MTI Leon Geyser
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] On the form of the question (was Re:… Markus.Isomaki
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] H.261 vs No MTI cb.list6
- Re: [rtcweb] H.261 vs No MTI cowwoc
- Re: [rtcweb] On the form of the question (was Re:… Ron