Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00

Adam Roach <adam@nostrum.com> Wed, 08 May 2013 18:24 UTC

Return-Path: <adam@nostrum.com>
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 9993E21F90B9 for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 11:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.471
X-Spam-Level:
X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 lU0A207eBTdl for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 11:24:57 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A80F421F8F41 for <rtcweb@ietf.org>; Wed, 8 May 2013 11:24:57 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r48IOpud074344 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 8 May 2013 13:24:51 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <518A9872.8060100@nostrum.com>
Date: Wed, 08 May 2013 13:24:50 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Dale R. Worley" <worley@ariadne.com>
References: <201305081617.r48GHkcx4369224@shell01.TheWorld.com>
In-Reply-To: <201305081617.r48GHkcx4369224@shell01.TheWorld.com>
Content-Type: multipart/alternative; boundary="------------040307040603070207080708"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Glare in draft-roach-rtcweb-glareless-add-00
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: Wed, 08 May 2013 18:24:58 -0000

On 5/8/13 11:17, Dale R. Worley wrote:
> I see that  draft-roach-rtcweb-glareless-add-00 eliminates glare a
 > the SDP offer/answer level, but it seems to do so by having glare at
 > the higher "solicitation" level -- the designated answer can discover
 > that it has received an offer that is not correspondent with the
 > solicitation that it has sent.  The result is that the proposal
 > includes a bunch of logic which has the structure of
 > glare-resolution logic.

The logic is actually much, much simpler in that it only requires 
queuing of an outstanding operation rather than the relatively messy 
(and time consuming) business of backing off and running timers.

I will also emphasize that the condition you're describing arises far, 
far less frequently than general glare. In the vast majority of the 
cases (where the number of m= sections is not changing), the queuing 
isn't even necessary. The only cases requiring queuing are those in 
which the offerer isn't trying to add streams but the answerer is.

> The benefit of the proposal is  that it avoids "When [glare] happens
 > mid-session, user experience can be negatively impacted." But I
 > don't fully understand what the negative user experience impact is or
 > how this proposal eliminates it -- given that glare can still
 > happen.

I don't think it's really fair to characterize the situation you're 
describing as glare. It's more of a system-wide enforcement of event 
ordering according to the order in which they occur at a cannonical 
observer. We've just arbitrarily chosen that observer to be whichever 
party offers first.

> As far as I can tell so far,  the core advantage is that this
 > proposal resolves glare faster than the RFC 3261 (section 14)
 > procedure because the designated answerer is required to process the
 > updated offer it receives even if that is not the updated offer it
 > has solicited.

I think the core advantage is that the situation in which any 
exceptional behavior arises is several orders of magnitude more rare 
than the situation in which generalized glare can arise.

> I haven't thought through the  details, but it seems to me that the
 > same effect could probably be achieved by negotiating an amendment
 > to the RFC 3261 glare-recovery procedure with similar properties...

Fixing 3261 does nothing for RTCWEB. We'd need to change 3264. :)

> There's also the question how  this gets negotiated across a gateway
 > to SIP.

Section 3.

/a