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

[Harald Alvestrand <[e-mail]>]

On 09/22/11 15:44, Cullen Jennings wrote:
> 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.
>
> Thoughts?
>
> 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.
>
Seems like it could be a really short I-D, but definitely needs to be 
written up.

Magnus' analysis worries me a bit, because it seems to assume specific 
functionality in the gateway (tracking of state and ability to generate 
SIP messages depending on state).
It seems reasonably simple to build a gateway, but we quickly get to the 
point where we have to write standards for the gateway function .... 
which could lead us down rather deep ratholes.