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