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
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- [rtcweb] Quick comments on draft-roach-rtcweb-gla… Ted Hardie
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Ted Hardie
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- [rtcweb] Glare in draft-roach-rtcweb-glareless-ad… Dale R. Worley
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Adam Roach
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Cullen Jennings
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Dale R. Worley
- [rtcweb] Reducing glare Dale R. Worley
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Paul Kyzivat
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Bernard Aboba
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Emil Ivov
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Emil Ivov
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Bernard Aboba
- Re: [rtcweb] Quick comments on draft-roach-rtcweb… Stefan Håkansson LK
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Emil Ivov
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Harald Alvestrand
- Re: [rtcweb] [MMUSIC] Quick comments on draft-roa… Stefan Håkansson LK
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Christer Holmberg
- Re: [rtcweb] Glare in draft-roach-rtcweb-glareles… Iñaki Baz Castillo
- Re: [rtcweb] Reducing glare Iñaki Baz Castillo