Subject: SIP Request Glare.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 23 Mar 2000 23:52:53 -0800

I refer to the clarification on "The SIP Page":

---
	CSeq
	The spec is not clear on whether both parties "share" the CSeq
space. In other words, if A sends an INVITE to B with CSeq: 0, and then B
sends a BYE to A, does B need use CSeq:1 in its BYE? Answer: no. The CSeq
space is maintained independently in both directions. This raises a state
inconsistency issue. Lets say A and B are in a call, and A sends a re-INVITE
to B at the same time B sends it to A. It is possible that the transactions
complete in different orders at A and B, yielding an inconsistent view of
the session state. This is similar to the "glare" problem in telephony. The
solution: if A has a transaction pending (pending = no final response
received), and a request from the remote side arrives, it should send a 500
response (possibly with a Retry-After randomly generated to enable back-
off). This should (??) guarantee ordered completion of transactions. 
---
Firstly concerning, request ordering and pending requests: Does order
consistency condition extend to other methods, such as glare between
METHOD-INFO & INFO-INFO request for example ? If not, then INFO and INVITE
methods must be able execute independently (that is, you could have multiple
active requests: an INVITE and an INFO, or two INFOs). What is the correct
handling of this situation ? 

Now regarding glare resolution: Is the proposed glare resolution solution
acceptable in a telephony environment? The granularity of Retry-After is in
seconds. So to have a reasonable chance of not colliding again you must make
the random range large; yet it is unacceptable to have a delay any more than
a second or two in most telephony applications. For instance if the random
range of Retry-After is up to three seconds, then this only allows three
random outcomes => leading to a roughly 33% chance of re-collision.
Additionally, even for this small value of Retry-After there is roughly only
a 66% chance that a request will commence within 2 seconds (which is still
unacceptable in many situations). Whether or not you have a small or large
random range for Retry-After doesn't help because of the lack of random
granularity.

We need a glare resolution that completes resolves quickly, does not starve
one side and has little chance of recollision. 

One possible solution might be to include a header field with a 32bit random
value ( eg Retry-Resolve?). Both sides can use this value to quickly resolve
the glare and the winner could instantly retransmit.

I am not sure if I have "gone off the rails" somewhere along the way but to
me it seems like this is a pretty big hole in the protocol. What are people
doing at the moment?

Cheers,

Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Mar 2000 00:07:11 -0500

> handling of this situation ?

The ordering is only important if the messages have an effect on shared
state. By its definition, INFO cannot affect call or session state.
Therefore, I believe it is safe to process an incoming INFO whilst
processing an outgoing INFO or INVITE or anything else. Among the set of
existing methods, I believe only INVITE has this problem.

Regarding the glare issue, Kelly later writes:
> We've introduced an alternate proposal in a recent I-D (see, in particular,
> section 7 of http://www.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt)
> that attempts to address the problem.  Loosely, our proposal entails
> comparing the URIs used in the To and From fields of the INVITEs as the
> basis for comparison.  The party whose URI is lesser is designated the
> victor when crossing INVITEs arise.

I'm afraid this solution does not work as specified. It only works if
both sides agree they are in a glare situation. Consider the following
case. A sends a reinvite to B. B receives it, and responds with a 200.
This response takes a while to get to A. Now, B sends a re-INVITE to A
(as far as B is concerned, the reinvite it received has been responded
to, thus there is no glare, and it can send a new re-INVITE). A receives
that re-invite. A thinks there is glare, and decides its the winner, so
it responds w/ a 200 OK. Then, A gets the non-500 response from B. Now A
is really confused.

You could argue that B shouldn't even send that re-INVITE until the ACK
is received for the re-INVITE B got first. However, there is still a
race condition that makes it not work, although its less likely. Heres
the case: A sends a re-invite to B that gets lost. B sends a re-invite
to A. A sees glare, and decides B should win, so it responds with a 200
OK. B ACKs, and A gets the ACK. Then, that lost reinvite arrives at B. B
thinks everything is fine, since the previous reinvite it sent has been
ACKed. So, it sends a 200 OK. Now, A is once again confused.

I think this can be fixed if each side includes, in a re-INVITE, the
CSeq of the request last received from the other party (or -1 or
something if it hasn't gotten one yet). This will allow each side to
determine, when it receives a reinvite while reinviting, whether the
reinvite it sent has been received and responded to by the other side.
This requires an extension, and its not backwards compatible, which is
kind of yucky. Below is an alternate solution.

> random range for Retry-After doesn't help because of the lack of random

Well, how about we add random granularity? We could simply say that both
sides should retry within a random time distributed between 0 and some
number. This number has to be chosen large enough to reduce the
probability of collision again, but small enough to make the re-invite
resolve quickly. Glare happens again if both sides choose a number
within 1/2 RTT of each other. Lets say 1/2 RTT = 50ms. If we want the
re-glare case to happen with < 5% probability, choosing the number
randomly between 0 and 1 second should work.

This solution doesn't require an extension. Its not as fast as above,
but its not as complex.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com