Subject: [Sipping] draft-ietf-sipping-race-examples: 491 in non glare situations

From: "Brett Tate" <[email-masked]>
Date: Wed, 2 May 2007 13:47:30 -0400

Greetings,

Concerning draft-ietf-sipping-race-examples-01 section 3.1.5 (and
alternative text of 3.1.4), why is a 491 response being recommended in a
non glare situation?

Sending a 500 with Retry-After seems more appropriate.  Just because one
side wants the other to try again 0-2 or 2-4 seconds later does not mean
the 491 should be returned instead of a 500 with Retry-After.

Thanks,
Brett

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 May 2007 17:50:23 -0400

> the 491 should be returned instead of a 500 with Retry-After.

3.1.5 appears to be a valid glare situation to me: Bob has an unanswered 
offer outstanding when it receives an offer.

This seems way more suitable than a 500 response, which suggests that 
something much more serious is going on than is actually the case.

In the case of 3.1.4 I think the primary recommendation (a 200 response 
to the reinvite) is preferred. Its based on an inference:

while I haven't received the ACK, a correctly functioning UA would not 
have sent this reinvite unless it had received my 2xx response. 
Therefore the ACK must have been lost.

We can discuss where a UA must be expected to be smart enough to make 
this inference. If yes, then we don't need to consider alternatives. If 
not, then I prefer 491 to 500 for the same reason as in the 3.1.5 case: 
this does appear to be a glare.

	Paul

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 2 May 2007 19:47:47 -0400

Hi Paul,

Thanks for the response.  Replies are inline. 

> > Concerning draft-ietf-sipping-race-examples-01 
> > section 3.1.5 (and alternative text of 3.1.4), 
> > why is a 491 response being recommended in 
> > a non glare situation?
> > 
> > Sending a 500 with Retry-After seems more appropriate.  
> > Just because one side wants the other to try again 0-2 
> > or 2-4 seconds later does not mean the 491 should be 
> > returned instead of a 500 with Retry-After.
> 
> 3.1.5 appears to be a valid glare situation to me: Bob has 
> an unanswered offer outstanding when it receives an offer.

The rfc3261 definition of 491 Request Pending is based upon request
glare.  The 491 algorithm of picking 0-2 and 2-4 is based upon request
glare.

Has something expanded the 491 definition?  RFC 3311 discusses it a
little.  It only indicates using 491 to resolve request glare instead of
glare with an offer sent within a 2xx response.  However I might be
misinterpreting the lack of responses mentioned within the parenthesis.
:)

"If an UPDATE is received that contains an offer, and the UAS has
generated an offer (in an UPDATE, PRACK or INVITE) to which it has not
yet received an answer, the UAS MUST reject the UPDATE with a 491
response."

> This seems way more suitable than a 500 response, which 
> suggests that something much more serious is going on 
> than is actually the case.

Why do you consider it more serious?  This was the mechanism for glare
recovery prior to rfc3261 defining the 491 for faster recovery.  And it
is the default response to request the sender to retry later.
Unfortunately some vendors are starting to send 491 in non glare
situations by default instead of using the 500 with Retry-After.

<snip>

> We can discuss where a UA must be expected to be smart enough 
> to make this inference. If yes, then we don't need to 
> consider alternatives. If not, then I prefer 491 to 500 for 
> the same reason as in the 3.1.5 case: 

See prior comments.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 May 2007 22:17:43 -0400

Brett,

IMO when we discover more glare-like conditions it is better to use the 
response pertaining to glare than to use a response that is less 
specific. In what way would 500 be more informative than 491?

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 3 May 2007 12:44:05 -0400

> IMO when we discover more glare-like conditions it is 
> better to use the response pertaining to glare than 
> to use a response that is less specific. In what way 
> would 500 be more informative than 491?

Hi Paul,

The 500 is more informative because the 491 indicates to try later
because collided with a request sent in opposite direction on the dialog
(unless definition is expanding).  The 500 indicates to try later.

I agree that the distinction between 491 and 500 can be subtle.  However
the distinction can be important to devices (B2BUA, gateway, etcetera)
unable to lose the glare recovery because of service complexities or
limitations related to other call halve.

I'm really just attempting ensure an exact definition of when 491 should
be sent since some are sending it for almost everything as an alternate
to 500 with Retry-After.  I assume that it is because they think the 491
appears less severe (or less of a problem) than the 500.  However it
could just be different interpretations of glare (and when the 491
should be sent).

IMO if the 491 definition is changing, an enhancement should be made to
avoid remaining tied to 491 glare resolution algorithm which is
specifically for request glare.

> >>> section 3.1.5 (and alternative text of 3.1.4), why is a 
> 491 response 
> >>> being recommended in a non glare situation?
> >>>
> >>> Just because one side wants the other to try again 0-2 or 2-4 
> >>> seconds later does not mean the 491 should be returned 
> instead of a 
> >>> 500 with Retry-After.
> >> 3.1.5 appears to be a valid glare situation to me: Bob has an 
> >> unanswered offer outstanding when it receives an offer.
> > 
> > little.  It only indicates using 491 to resolve request 
> glare instead 
> > of glare with an offer sent within a 2xx response.  However 
> I might be 
> suggests that 
> > recovery prior to rfc3261 defining the 491 for faster 
> recovery.  And 
> > it is the default response to request the sender to retry later.
> >> this inference. If yes, then we don't need to consider 
> alternatives. 
> >> If not, then I prefer 491 to 500 for the same reason as in 
> the 3.1.5 
> >> case:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 May 2007 13:28:25 -0400

> specifically for request glare.

I realized a long time ago that there were more kinds of glare than are 
mentioned in 3261. This draft digs into those. They are in fact glare 
just as much as the cases covered by 3261, so IMO it is better to apply 
491 to them than 500 which applies to so many cases that it is very 
difficult to determine what the real problem was.

But lets see what other people have to say.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 17 May 2007 10:29:06 +0300

Hi,

I believe 491 is appropriate because we are dealing with glare 
conditions anyway, even if they were not explicitly described in RFC 3261.

Cheers,

Gonzalo

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 May 2007 14:40:35 -0400

> I believe 491 is appropriate because we are dealing 
> with glare conditions anyway, even if they were not 
> explicitly described in RFC 3261.

I agree that there is "glare" of some type.  However the following are a
few reasons why I think it would be best to keep the 491 Request Pending
limited to the glare discussed within rfc3261.

1) The glare resolution algorithm triggered by a 491 is specifically for
request glare.  Otherwise there is no reason why the receiver needs to
act differently based upon Call-ID ownership.

2) If a precise definition is not used (such as rfc3261's "Request
Pending") vendors will basically start generating 491 based upon how
they individually define glare and if the 491 resolution algorithm is
acceptable to help resolve it.

3) The current rfc3261 definition of 491 indicates that the other side
is attempting to deliver a request.  Changing the definition in ways
such as draft-ietf-sipping-race-examples basically turns the 491 into a
"retry per 491 algorithm" since the receiver will no longer know if the
sender of 491 is/was actually trying to deliver a request.  

I agree with Paul's comment that the 500 is used for too many different
things.  And I especially dislike that the 500 is used for cseq ordering
problems.  However I think that expanding the definition of 491 makes
the 491 also vague.  Concerning the many usages of the 500 response, it
might be better to create additional response codes or clarifying
headers/parameters instead of causing other response codes to have
similar problems.

I'm actually not overly opposed to the definition of 491 being expanded.
It is just that it basically will become the catch all response to retry
later when the algorithm is an acceptable alternative to 500 with
Retry-After.  If expanding the definition, I guess that the next step
would be to standardize something for inclusion within the 491 so the
reason can be clearly indicated and no longer tied to the current
request glare algorithm.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 May 2007 15:51:56 -0400

Brett,

Would you be happy if we came up with a definition of "glare" that is 
clear about what is and isn't glare? Then we would have a good rule for 
when 491 applies.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 May 2007 19:22:13 -0500

On May 17, 2007, at 2:51 PM, Paul Kyzivat wrote:

> Brett,
>
> Would you be happy if we came up with a definition of "glare" that  
> is clear about what is and isn't glare? Then we would have a good  
> rule for when 491 applies.

I don't know about Brett, but that would just rock my socks (and  
that's a good thing). I've been confused about what is and isn't  
glare since before I finally figured out what HERFP stood for.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 10:02:39 -0400

Dean Willis wrote:
>> clear about what is and isn't glare? Then we would have a good rule 
>> for when 491 applies.
> 
> I don't know about Brett, but that would just rock my socks (and that's 
> a good thing). I've been confused about what is and isn't glare since 
> before I finally figured out what HERFP stood for.

OK. I'm not saying that I actually *have* a definition ready to roll off 
my fingertips. Up till now that has been one of those "you know it when 
you see it" kind of things. At one point several years ago when I was 
working on something related I know I identified several things beyond 
what is in 3261 that also seemed like glare. I think all of those ended 
up in race-examples. Operationally I think we might start by saying that 
glare is what the race-examples call glare. But I realize that isn't 
very satisfying.

	Paul

-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4IE2b5t015749; 
	Fri, 18 May 2007 14:02:47 GMT
Date: Fri, 18 May 2007 10:02:39 -0400
From: Paul Kyzivat <[email-masked]>
To: Dean Willis <[email-masked]>
Subject: Re: [Sipping] Re: draft-ietf-sipping-race-examples: 491 in non
	glaresituations
Cc: [email-masked], [email-masked],
	Gonzalo Camarillo <[email-masked]>,
	Brett Tate <[email-masked]>

Dean Willis wrote:
>> clear about what is and isn't glare? Then we would have a good rule 
>> for when 491 applies.
> 
> I don't know about Brett, but that would just rock my socks (and that's 
> a good thing). I've been confused about what is and isn't glare since 
> before I finally figured out what HERFP stood for.

OK. I'm not saying that I actually *have* a definition ready to roll off 
my fingertips. Up till now that has been one of those "you know it when 
you see it" kind of things. At one point several years ago when I was 
working on something related I know I identified several things beyond 
what is in 3261 that also seemed like glare. I think all of those ended 
up in race-examples. Operationally I think we might start by saying that 
glare is what the race-examples call glare. But I realize that isn't 
very satisfying.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 18 May 2007 12:46:43 -0400

Hi Paul,

RFC 3261 already defines when the 491 Request Pending should be used;
and it provides the corresponding algorithm.  The Call-ID ownership
aspects of the request glare resolution algorithm will remain a strange
side effect of expanding rfc3261's definition unless further
enhancements are made.

If the 491 Request Pending definition is expanded, yes it would be good
if the definition continues to be as precise as I think rfc3261 is but
apparently isn't.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2007 3:52 PM
> To: Brett Tate
> Cc: Gonzalo Camarillo; [email-masked]; [email-masked]
> Subject: Re: [Sipping] Re: draft-ietf-sipping-race-examples: 
> 491 in non glaresituations
> 
> Brett,
> 
> Would you be happy if we came up with a definition of "glare" 
> that is clear about what is and isn't glare? Then we would 
> have a good rule for when 491 applies.
> 
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2007 15:21:58 -0400

> side effect of expanding rfc3261's definition unless further

3261 wasn't prescient about extensions. (It tried to be about UPDATE and 
PRACK, but wasn't complete.)

As I see it, callid ownership is used to pick which of the two reinvites 
should get precedence. Its only necessary to have *some* algorithm that 
both sides will be able to execute and get the same result. This was 
needed because both sides are sending reINVITES and so can't distinguish 
based on method, etc.

In some of the other cases of glare there are other ways of picking. 
E.g. with a reINVITE vs. an UPDATE we could simply declare that one or 
the other always wins. Or we could use the callid algorithm. (I must say 
that I don't understand why the *winner* must wait a random delay before 
retrying. Retrying immediately seems to present no problems.)

In race-example 3.1.4 the recommendation is to use a 200 in F8, with 491 
noted as also being acceptable. This is arguably not a glare case, so we 
could potentially just remove the mention of 491.

In 3.1.5 is *is* a glare condition because Bob has an offer outstanding 
and unanswered, and gets a new offer from Alice. So I think 491 is the 
right response. But the retry algorithm is different in this case. (It 
seems that we will need to specify this somewhere, which will indeed 
require a normative document.) Because of the asymetry of the situation, 
using callid seems inappropriate. Vijay has suggested something here, I 
will discuss when I reply to him.

> if the definition continues to be as precise as I think rfc3261 is but

After reviewing the various docs, I think that glare is the situation 
where you receive an offer while you have an unanswered offer 
outstanding. And in this case you return 491 if you can. (In the case 
where you made the offer in a 2xx you can't, and so you must expect that 
the other side will figure it out.)

The 3.1.4 case is special because the receipt of a reINVITE is evidence 
that the other side received your 200 with the answer. (It is *illegal*, 
not a race, for the other side to send a reINVITE with an offer before 
it has received an answer to its prior offer.) So it is reasonable to 
consider the new offer to be valid.

I think the bottom line here is that when the glare condition is 
something other than invite vs invite there is no documented algorithm 
for deciding who goes first and when. That needs to be documented 
somewhere in a normative document.

	Paul

---

From: [email-masked]
Date: Sat, 19 May 2007 08:11:21 -0400

From: "Brett Tate" <[email-masked]>

A much better way to phrase the question is "What, exactly, is the
'glare' that response 491 indicates?"

The official definition is

   21.4.27 491 Request Pending

   The request was received by a UAS that had a pending request within
   the same dialog.  Section 14.2 describes how such "glare" situations
   are resolved.

which is quite insufficient, as in general it's legal to send a
request to the other end while the other end has a request to you
pending.

It seems to me that the definition "UAS received an offer while it had
an offer outstanding" (= "required to reject an offer at this time due
to the offer/answer rules") is a good one.  It is also a good
definition to say "UAS requests UAC to use the retry algorithm at the
top of page 88".  It would be a *really good* definition if those were
both the *same*, but that is a question of fact to be investigated.

The tremendous advantage of 491 over 500 in this sort of situation is
that it has an asymmetric retry algorithm which has a high
probability of resolving the conflict in one round with small delays.

   From: "Brett Tate" <[email-masked]>

   I agree that the distinction between 491 and 500 can be subtle.
   However the distinction can be important to devices (B2BUA,
   gateway, etcetera) unable to lose the glare recovery because of
   service complexities or limitations related to other call halve.

Can you explain this in more detail?

   From: "Brett Tate" <[email-masked]>

   I agree with Paul's comment that the 500 is used for too many
   different things.  And I especially dislike that the 500 is used
   for cseq ordering problems.

Yes, 500 for "out of order" is particularly bad.  Especially because
it's in the wrong *class*, an out-of-order error is a problem with the
request, not a problem with the UAS, and so should be a 4xx response.
I assume this is some grandfathered mistake from the early days of
2543.

   OK. I'm not saying that I actually *have* a definition ready to roll off 
   my fingertips. Up till now that has been one of those "you know it when 
   you see it" kind of things.

That is a good way to generate interoperability problems.  If people
had thought through what glare was in previous RFCs, we wouldn't need
the race-examples draft (which was stimulated by problems seen in
implementations).

Dale

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 21 May 2007 11:32:55 -0400

> A much better way to phrase the question is "What, exactly, 
> is the 'glare' that response 491 indicates?"

Per rfc3261 section 21.4.27 and the resolution algorithm, my
understanding is that the glare is between requests sent in opposite
directions over the same dialog.

>   The request was received by a UAS that had a pending 
>   request within the same dialog.  Section 14.2 describes 
>   how such "glare" situations are resolved.
> 
> which is quite insufficient, as in general it's legal to send 
> a request to the other end while the other end has a request 
> to you pending.

Yes; it is usually legal or tolerable.  However when one or both parties
thinks the colliding requests are intolerable (usually because of
potential ambiguity); the 491 helps rectify the situation.

> It seems to me that the definition "UAS received an offer 
> while it had an offer outstanding" (= "required to reject an 
> offer at this time due to the offer/answer rules") is a good 
> one.  It is also a good definition to say "UAS requests UAC 
> to use the retry algorithm at the top of page 88".  It would 
> be a *really good* definition if those were both the *same*, 
> but that is a question of fact to be investigated.

The 491 Request Pending is not limited to offer/answer.  However
colliding requests related to offer/answer is the most common trigger of
a 491.

> The tremendous advantage of 491 over 500 in this sort of 
> situation is that it has an asymmetric retry algorithm which 
> has a high probability of resolving the conflict in one round 
> with small delays.

Yes.  However my draft-ietf-sipping-race-examples comment is associated
with a call-flow which does not need the usage of the 491 because it
isn't two requests colliding.

> Can you explain this in more detail?

Situations exist where a device might be willing to delay before
resending a request but not willing or able to lose the request glare.
The inability to lose the glare can be because of various factors such
as B2BUA/gateway being to connected to device or protocol which requires
winning the glare.

If 491 starts being sent in non request glare situations, it is hard to
know if the device is just asking for a delay or is/was trying to
deliver a request.

> Yes, 500 for "out of order" is particularly bad.  Especially 
> because it's in the wrong *class*, an out-of-order error is a 
> problem with the request, not a problem with the UAS, and so 
> should be a 4xx response.
> I assume this is some grandfathered mistake from the early 
> days of 2543.

A 400 was recommended by rfc2543.  I don't immediately recall why it was
changed to 500.  I assume that it was changed to 500 because it helps
resolve the problem and some didn't think it warranted it's own response
at the time.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 12:53:46 -0400

OK. I think maybe I am starting to understand Brett's problem.

One question is whether 3261 says what it meant, or should have meant.

There are indeed potentially two kinds of problems here:

- an offer received when there is an unanswered offer outstanding.
   We now have several examples of this in the race-examples draft.

- two requests sent in opposite directions that conflict in some way.
   E.g. Two UPDATE requests, one from each side, that don't contain
   offers. I guess an UPDATE without an offer and a reINVITE without
   an offer, or two reINVITEs without offers also qualify here.
   (Maybe there are also some other cases.)

Lets call these things "O/A Glare" and "Request Glare". Many of the 
common examples have both problems.

Are there real cases when Request Glare is a problem in the absence of 
O/A Glare? When/why would it be?

- Two UPDATEs could do target refresh. This doesn't really conflict
   as long as they each respond with their new target. For each the
   old target must still work until the request succeeds.

- Two UPDATEs could attempt to change session timer state.
   I think there are cases where this could be a problem.

- An UPDATE without offer vs a reINVITE: both could attempt to
   change session timer state. I guess this is potentially also
   a real problem.

I can't think of anything else.

Potentially there could be different responses for the O/A Glare and 
Request Glare. But then there would be need of a priority for those 
cases when both problems exist. And of course we would then need to 
decide which one gets to keep 491 and which gets a new code.

Alternately, we could continue to use 491 for both problems and specify 
what the proper course of action is when receiving 491 in different 
cases. Frankly I'd rather stick with 491 unless we identify some 
ambiguity that can't be resolved that way. Unless there are more cases 
than I noted above I don't see a problem disambiguating.

As applies to the race-examples draft, which is to be a BCP, we need to 
decide how we are going to handle these issues that seem to require 
normative changes. My inclination is to have race-examples recommend 491 
in all these cases, and *recommend* behavior for handling 491, but leave 
making that behavior normative to some other draft.

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 23 May 2007 19:57:56 -0700

Paul,

Couple comments inline...

>   We now have several examples of this in the race-examples draft.

Is the goal to exhaustively list all such races? Currently it doesn't 
include those involving PRACK, e.g. PRACK with offer vs. UPDATE with 
offer. I don't think it's necessary to list all combinations but it 
should be mentioned that the list is not complete.

>   old target must still work until the request succeeds.

In this case the two UPDATEs are not ordered relative to one another so 
if UA 1 changes Contact to X in its UPDATE and to Y in response to UA 
2's UPDATE there's no telling which one takes effect at UA 2.  This 
would appear to be an issue whenever two target refresh requests cross 
on the wire.

Thanks,
Anders

>>>   The request was received by a UAS that had a pending   request 
>>> within the same dialog.  Section 14.2 describes   how such "glare" 
>>> situations are resolved.
>>>
>>> It seems to me that the definition "UAS received an offer while it 
>>> had an offer outstanding" (= "required to reject an offer at this 
>>> time due to the offer/answer rules") is a good one.  It is also a 
>>> good definition to say "UAS requests UAC to use the retry algorithm 
>>> at the top of page 88".  It would be a *really good* definition if 
>>> those were both the *same*, but that is a question of fact to be 
>>> investigated.
>>
>>> it's in the wrong *class*, an out-of-order error is a problem with 
>>> the request, not a problem with the UAS, and so should be a 4xx 
>>> response.
>>> I assume this is some grandfathered mistake from the early days of 2543.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 May 2007 09:32:48 -0400

> should be mentioned that the list is not complete.

IMO the goal is to cover the *unique* cases to the extent that we can 
identify them. When there are variants that are so similar that its 
clear the same answers apply then I don't think we need to cover them.

> would appear to be an issue whenever two target refresh requests cross 

A reasonable UA that is changing its contact address will hopefully do 
it at some point in time and consistently report the new value from that 
point on.

Of course there could be an issue if there is need to change the contact 
address *again* before it is clear that the earlier change has been 
understood by the peer. I don't think that is a case worth discussing.

	Paul

>> Alternately, we could continue to use 491 for both problems and 
>> specify what the proper course of action is when receiving 491 in 
>> different cases. Frankly I'd rather stick with 491 unless we identify 
>> some ambiguity that can't be resolved that way. Unless there are more 
>> cases than I noted above I don't see a problem disambiguating.
>>
>> As applies to the race-examples draft, which is to be a BCP, we need 
>> to decide how we are going to handle these issues that seem to require 
>> normative changes. My inclination is to have race-examples recommend 
>> 491 in all these cases, and *recommend* behavior for handling 491, but 
>> leave making that behavior normative to some other draft.
>>
>>     Paul
>>
>> Brett Tate wrote:
>>>> The tremendous advantage of 491 over 500 in this sort of situation 
>>>> is that it has an asymmetric retry algorithm which has a high