[rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism

Cullen Jennings <fluffy@cisco.com> Thu, 22 September 2011 13:42 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9471121F8AFA for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.111
X-Spam-Status: No, score=-103.111 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oOCi7n3mKG-S for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 06:42:12 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id E5B3221F8AF8 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 06:42:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=2706; q=dns/txt; s=iport; t=1316699084; x=1317908684; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FJh0KYhhWXBXCnWBbHjjsouh/BLzZhfEBJPnBpT7ZFg=; b=krJBK2/jRyDNbKdAmUtIMFEMW5iuIagNdlh22/mr1rDEcHadJ4F2Trl4 a9Q4Eyd/T+340wrBu2CsT2lu40ypKzTQ0+C8i/Z3MapChe6KQ8XLDTHNs Ptyx48ZlYkGsQgh+ZVlsVY1ClVzaj4ZdjTxUzel3/P+ICj+prqAtwuw1K s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAG46e06rRDoJ/2dsb2JhbABCqAB4gVMBAQEBAgESASc/BQtRVwYxAQOHVpZWAZ4uhh1gBIdxi1+FH4wv
X-IronPort-AV: E=Sophos;i="4.68,423,1312156800"; d="scan'208";a="3653065"
Received: from mtv-core-4.cisco.com ([]) by mtv-iport-1.cisco.com with ESMTP; 22 Sep 2011 13:44:44 +0000
Received: from [] (sjc-fluffy-8914.cisco.com []) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8MDihF1003326; Thu, 22 Sep 2011 13:44:43 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4E799ECC.8030306@ericsson.com>
Date: Thu, 22 Sep 2011 07:44:43 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB6B2796-9762-47CA-9A45-62476146DF04@cisco.com>
References: <4E777500.5030201@alvestrand.no> <4E78940C.4040405@ericsson.com> <ED2DB00E-A64B-405F-96AC-2269258F6FFC@cisco.com> <4E799ECC.8030306@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: [rtcweb] SIP Glare - Re: Minimal SDP negotiation mechanism
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: Thu, 22 Sep 2011 13:42:13 -0000

On Sep 21, 2011, at 2:22 AM, Magnus Westerlund wrote:

> And why, did you design such a poor glare handling algorithm for SIP? ;-)

So, the SIP glare algorithm leaves much to be desired, no questions about it. I'm going to claim I was not there at the time until someone proves otherwise then switch my story to I was drunk not stupid. (in fairness we were trying to be backwards compatible with 2543 equipment).

Anyways, I've been bouncing ideas around with folks on how we might improve the situation. Here is a proposal that might improve it for SIP and could also be leveraged by RTCWeb. 

First, to review the current situation, the current algorithm is:

When two sides detect glare, they each pick a random integer from 1 to 10 and tell the other side to retry in that many seconds. two obvious problems with this: 1) it introduces, on average, over 7 seconds of delay which is a long time for a user 2) it has a non trivial chance of having glare a second time and needing to be repeat

I'm proposing an extension that would go something like this:

Both sides always include a random tie breaker number in their SDP that is used for glare resolution. If both sides support this and have the number, then glare is resolved by whoever has the lowest number. 

If neither side supports this, obviously the current things is what happens. 

if one side supports it but the other does not, the side that supports it tells the other side to retry after 0 seconds. So effectively it causes the other side to always "win" the tie and retry first. This reduces the latency of the glare resolution to the end user. The other side that does not support the new algorithm will still send a retry after some random number form 1 to 10 seconds. However, the side that supports this new mechanisms might want to decide that under some conditions, ti can short circuit that timer and retry sooner than that. It's not exactly clear to me when to short circuit this. Could it short circuit after receiving the retied transaction from the other side plus a one RTT delay? Could we just retry after 3 RTT or so knowing the other side won the race and was retying immediately? 

Even if the UA just runs out the full retry time, this algorithm still reduces the average delay significantly for cases where only one side supports it and gets really fast when both sides support it. 


I suspect this would need an SDP extension to carry the tie breaker number or even if we used an existing number, it seems like we still need something that indicates support for this new extension.