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

[Dzonatas Sol <[e-mail]>]

On 09/22/2011 10:37 AM, Harald Alvestrand wrote:
> 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.


May seem like that for mobiles, and even for mobile applications even if 
the unit is stationary. I think we can talk about gateways easier than 
blackboxes, especially the kind that are mostly like on-board each 
future car and have relatively stationary apps (from concept car to 
"printed" driverless vehicles that rolls itself to destination of the 
build order).

The initial roll-off: best done with nothing explosive, so we get into 
suspend-states and solid-states.

Both lead to gateways, so my perspective is the browser on the gateway 
rather than the browser on the mobile. One can "key-in" much like 
"dial-in", so we can limit ICE here in this model within range of the 
gateway (on the wire).

Capture the moment. If we clone that moment unto the next vehicle then 
do we worry if the same random number appears the same after suspend? 
Remember that the "power supply is suspended" yet there is energy from 
somewhere that completes this initial roll-off.

Win? Maybe we can show the fuel icon with an estimated time until 
refueled again or... until next cybernetic "prime" because you know 
the-new-owner can than innovate rather than think about scalable 
self-assembly (i.e. ag), or at least on the run-way this looks more out 
in the open... for "observation" (as over 200,000 of these clones 
roll-off each day).

Maybe the one ahead should help power the build for the one behind, the 
digital divide.

-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>