Subject: [Sipping] WGLC review of draft-ietf-sipping-race-examples-01

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 18 May 2007 09:02:34 -0500

Draft: draft-ietf-sipping-race-examples-01.txt
Reviewer: Vijay K. Gurbani
Review Date: 18 May 2007
Review Deadline: 18 May 2007 (Extended)
Status: WGLC

Summary: This draft is on the right track but has open issues,
described in the review.

This is a good draft.  It attempts to fill in the blanks of rfc3261
with respect to some race conditions.  It should be helpful to
implementors.  Not sure whether it makes sense to hang some of
these tests on the SIPit site for new implementations, but it
may be well worth considering it.

Global comments:

1) On a philosophical note, I believe that you are attempting to
   clarify the race conditions inherent in rfc3261, not in rfc4235.
   To that extent, it may be best to simply start S2 with a state
   machines of an early dialog from rfc3261: early, confirmed, and
   terminated (also, pedantically speaking, these states are not as
   much "shown in RFC3261" as they are "described in RFC3261."  I
   believe that the closest definition is in the last paragraph of
   S12 in rfc3261).

   So, if you accept my premise, then starting with something like
   this should help the reader, regardless of whether or not they
   are familiar with rfc4235:

   For the UAC:
   R: Received
   S: Sent
               +--- R(1xx)
               v
          +->+-------+
    R(1xx)|  | Early |-----------------+
          +--+--+----+                 |
             |  | R(2xx)               |
          +--+  v                      |
          |  +-----------+             |
          |  | Confirmed |---+         | S(CANCEL) &&
    R(non-|  +-----------+   | R(BYE)  | R(487-INV)
      2xx)|     |S(BYE) +----+         |
         From [email-masked] Fri May 18 10:03:08 2007
Date: Fri, 18 May 2007 09:02:34 -0500
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: SIPPING LIST <[email-masked]>
Cc: [email-masked], Gonzalo Camarillo <[email-masked]>,
	Mary Barnes <[email-masked]>, [email-masked]
Subject: [Sipping] WGLC review of draft-ietf-sipping-race-examples-01

Draft: draft-ietf-sipping-race-examples-01.txt
Reviewer: Vijay K. Gurbani
Review Date: 18 May 2007
Review Deadline: 18 May 2007 (Extended)
Status: WGLC

Summary: This draft is on the right track but has open issues,
described in the review.

This is a good draft.  It attempts to fill in the blanks of rfc3261
with respect to some race conditions.  It should be helpful to
implementors.  Not sure whether it makes sense to hang some of
these tests on the SIPit site for new implementations, but it
may be well worth considering it.

Global comments:

1) On a philosophical note, I believe that you are attempting to
   clarify the race conditions inherent in rfc3261, not in rfc4235.
   To that extent, it may be best to simply start S2 with a state
   machines of an early dialog from rfc3261: early, confirmed, and
   terminated (also, pedantically speaking, these states are not as
   much "shown in RFC3261" as they are "described in RFC3261."  I
   believe that the closest definition is in the last paragraph of
   S12 in rfc3261).

   So, if you accept my premise, then starting with something like
   this should help the reader, regardless of whether or not they
   are familiar with rfc4235:

   For the UAC:
   R: Received
   S: Sent
               +--- R(1xx)
               v
          +->+-------+
    R(1xx)|  | Early |-----------------+
          +--+--+----+                 |
             |  | R(2xx)               |
          +--+  v                      |
          |  +-----------+             |
          |  | Confirmed |---+         | S(CANCEL) &&
    R(non-|  +-----------+   | R(BYE)  | R(487-INV)
      2xx)|     |S(BYE) +----+         |
          |     v       v              |
          |  +------------+            |
          +->| Terminated |<-----------+
             +------------+

   For the UAS:
   R: Received
   S: Sent
                      +--- R(INV) && S(1xx)
                      v
                     +-------+
   R(BYE) +----------| Early |-----------------+
     or   |          +--+----+                 |
   R(CAN) |             | S(2xx)               |
          |             v                      |
          |       +->+-----------+             |
          | R(CAN)|  | Confirmed |---+         | S(non-2xx)
          |       +--+-----------+   | R(BYE)  |
          |             |S(BYE) +----+         |
          |             v       v              |
          |          +------------+            |
          +--------->| Terminated |<-----------+
                     +------------+

   Then, you can add your super-state of Preparative to these, as
   well as further subdivide Confirmed and Terminated states and
   proceed as you do in the draft.

2) Several places, the prefix "ini-" is used before the word "INVITE".
   I presume you mean the initial INVITE.  If so, just explain it as such
   on the first use of the prefix.

3)  You may want to consider putting a blank line between paragraphs
   for readability.

4)  This is a BCP, right?  If so, I find the normative text a bit
   distracting.

5)  At various places, you use the word "signals", i.e., "Only
   significant signals are illustrated."  What you mean, I believe,
   is "signaling"; so, you may want to consider changing the occurrence
   of signals to signaling, as in: "Only significant signaling messages
   are shown."

6)  In some call flows, a substantial amount of information on the
  signaling aspect is provided, including SDP.  Other flows simply
  include a mnemonic like "F12 200 OK Alice -> Bob".  Is the fact
  that more information is provided beyond a mnemonic germaine to
  the reader?  That is, should the reader spent more (careful) time
  reading the SDP in signaling?  Please clarify.

The rest of the comments are sorted by the section.

1)  S2, Figures 1 and 2 - The timers (Timer K and Timer J)
  may confuse the reader.  Essentially, you are using two ideas in
  one place: a dialog-level state machines augmented with
  transaction-related timers.  It may be better to simply label
  Timers K and J as "Timeout" and then explain in the writeup
  that "This timeout corresponds to the lifetime of the BYE
  transaction at the UAS and UAC."

2)  S3.1.3 - You should (again) emphasize why sending BYE on an
   early dialog is not recommended.  Yes, rfc3261 allows the UAC to
   do so, but point the reader to Appendix A one more time and
   exhort them NOT to do this.

3)  S3.1.4 - I do not understand the resolution to this problem.
   Wouldn't an easier (and better?) resolution be that the UAC
   simply wait a bit longer (at least 2xT1 or 3xT1) before sending
   a re-INV?  That should, under most cases, ensure that if the
   ACK from the UAC was lost, the UAC will see a retransmitted
   200 OK.

4)  S3.1.5 - Same feedback as above.

5)  S3.1.6 - How feasible is the scenario here?  That is, are
   there UAs in the wild that will start a session when *after*
   sending a BYE, they see a retransmitted 200 OK (INVITE)?
   In other words, I don't view this neccessarily as a race
   condition as much as I view it as the need to apply solid
   defensive programming: If I get a 200 OK whose dialog
   identifiers match a dialog that is now in the terminated state,
   why would I want to resurrect the call again?  Clearly, the
   state machine driving my behavior as a UAC tells me that
   last arriving 200 OK (INVITE) should be discarded (much like
   we discard a CANCEL at a UAS if it arrives *after* a UAS has
   generated a final response.)

6)  S3.3 - Nit - s/Here explains/Here, we explain

7)  S3.3 - I am not sure what the authors mean by the phrase
  "What is established by SIP."  Please elaborate.

8)  Appendix B - I am not sure I understand the reasoning here.
   The UAC sends a BYE immed |     v       v              |
          |  +------------+            |
          +->| Terminated |<-----------+
             +------------+

   For the UAS:
   R: Received
   S: Sent
                      +--- R(INV) && S(1xx)
                      v
                     +-------+
   R(BYE) +----------| Early |-----------------+
     or   |          +--+----+                 |
   R(CAN) |             | S(2xx)               |
          |             v                      |
          |       +->+-----------+             |
          | R(CAN)|  | Confirmed |---+         | S(non-2xx)
          |       +--+-----------+   | R(BYE)  |
          |             |S(BYE) +----+         |
          |             v       v              |
          |          +------------+            |
          +--------->| Terminated |<-----------+
                     +------------+

   Then, you can add your super-state of Preparative to these, as
   well as further subdivide Confirmed and Terminated states and
   proceed as you do in the draft.

2) Several places, the prefix "ini-" is used before the word "INVITE".
   I presume you mean the initial INVITE.  If so, just explain it as such
   on the first use of the prefix.

3)  You may want to consider putting a blank line between paragraphs
   for readability.

4)  This is a BCP, right?  If so, I find the normative text a bit
   distracting.

5)  At various places, you use the word "signals", i.e., "Only
   significant signals are illustrated."  What you mean, I believe,
   is "signaling"; so, you may want to consider changing the occurrence
   of signals to signaling, as in: "Only significant signaling messages
   are shown."

6)  In some call flows, a substantial amount of information on the
  signaling aspect is provided, including SDP.  Other flows simply
  include a mnemonic like "F12 200 OK Alice -> Bob".  Is the fact
  that more information is provided beyond a mnemonic germaine to
  the reader?  That is, should the reader spent more (careful) time
  reading the SDP in signaling?  Please clarify.

The rest of the comments are sorted by the section.

1)  S2, Figures 1 and 2 - The timers (Timer K and Timer J)
  may confuse the reader.  Essentially, you are using two ideas in
  one place: a dialog-level state machines augmented with
  transaction-related timers.  It may be better to simply label
  Timers K and J as "Timeout" and then explain in the writeup
  that "This timeout corresponds to the lifetime of the BYE
  transaction at the UAS and UAC."

2)  S3.1.3 - You should (again) emphasize why sending BYE on an
   early dialog is not recommended.  Yes, rfc3261 allows the UAC to
   do so, but point the reader to Appendix A one more time and
   exhort them NOT to do this.

3)  S3.1.4 - I do not understand the resolution to this problem.
   Wouldn't an easier (and better?) resolution be that the UAC
   simply wait a bit longer (at least 2xT1 or 3xT1) before sending
   a re-INV?  That should, under most cases, ensure that if the
   ACK from the UAC was lost, the UAC will see a retransmitted
   200 OK.

4)  S3.1.5 - Same feedback as above.

5)  S3.1.6 - How feasible is the scenario here?  That is, are
   there UAs in the wild that will start a session when *after*
   sending a BYE, they see a retransmitted 200 OK (INVITE)?
   In other words, I don't view this neccessarily as a race
   condition as much as I view it as the need to apply solid
   defensive programming: If I get a 200 OK whose dialog
   identifiers match a dialog that is now in the terminated state,
   why would I want to resurrect the call again?  Clearly, the
   state machine driving my behavior as a UAC tells me that
   last arriving 200 OK (INVITE) should be discarded (much like
   we discard a CANCEL at a UAS if it arrives *after* a UAS has
   generated a final response.)

6)  S3.3 - Nit - s/Here explains/Here, we explain

7)  S3.3 - I am not sure what the authors mean by the phrase
  "What is established by SIP."  Please elaborate.

8)  Appendix B - I am not sure I understand the reasoning here.
   The UAC sends a BYE immediately following a re-INV.  This will
   typically happen if the user associated with the UAC presses
   the "Mute" button (say), followed immediately by hanging up.

   Now, here is where the actions of the user should be decoupled
   from the actions at the protocol level.  When the user presses
   the "Mute" button, the transaction layer generates a re-INV.
   Now, if the user immediately hangs up, the transaction layer
   can be smart and *defer* sending the BYE until the re-INV has
   completed successfully.  In other words, the transaction layer
   at the sender knows what has just occurred, so by quarantining
   the BYE until a response to the re-INV has been received, it
   can save the UAS a fair amount of protocol grief.

   Would it be better to simply provide guidance to quarantine
   the BYE in such cases until the re-INV transaction has finished?
   That seems easy enough.

9) In Appendix D, you should point out that a CANCEL request, regard-
   less of when it is received must always elicit a final response.
   Long time ago in SIP, we had a mantra: "every transaction completes
   independent of others" -- and it is worth documenting this mantra
   here.  Thus, if a CANCEL elicits a 487 (INVITE), the 487 completes
   the INVITE transaction and the CANCEL itself should be answered by
   a 200.

10)  I think it is worth adding a test case that documents forking
   at a proxy, all branches returning a non-2xx, and the proxy
   aggregating and choosing the best response, but inserting it's
   own tag in the To header of the non-2xx response.  The UAC will
   have got multiple 1xx responses with different tags, but when it
   gets a final response, the tag in the To will not match any of
   the early dialogs.

   But this is okay.  A UAC must be prepared to deal with this
   eventuality; rfc3261 only mandates that the 200 OK has the same
   From-tag that the 1xx response corresponding the 200 OK did.
   Proxies may want to insert their own To-tag in an aggregated
   non-2xx response for various reasons, some of which are detailed
   in the last paragraph of Step 6 in S16.7 of rfc3261.  This is
   an area where I am sure some implementations may falter and
   expect a tag in a previous 1xx corresponding to a forked branch.
   If you like, I can send you a prototypical example.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
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: Fri, 18 May 2007 19:35:32 -0400

Vijay,

Thank you for the careful review. Comments inline.

	Paul

>   are familiar with rfc4235:

If I understand, you are simply proposing a different way to get to the 
same place, without mentioning 4235, right?

I can see pros and cons to this. This stuff is hard. Someone trying to 
understand it would do well to look at 4235 as well, and the connections 
between all of these are helpful.

But ultimately I can go either way.

> 3)  You may want to consider putting a blank line between paragraphs

I agree. This is really an oversight rather than a stylistic issue (its 
currently both ways.)

> 4)  This is a BCP, right?  If so, I find the normative text a bit

I'm not clear on the rules. I think I saw someone say that normative 
language is ok in a BCP - that it defines what is required to conform to 
the best practices.

I looked at a number of occurrences of MUST, and all the ones I saw wer 
effectively restating normative language from the base RFCs. I would 
think this is appropriate.

>   of signals to signaling, as in: "Only significant signaling messages

Sounds good.

>  reading the SDP in signaling?  Please clarify.

We have refined this over time, after getting other feedback. In general 
the info in the messages that is relevant to this draft is the messaage 
type, To/From with tags, CSeq, and presence/absence of SDP and whether 
the SDP is same as some previous one. Sometimes more of this detail is 
needed than others, and its hard to get it all into the single line forms.

As I recall we also got feedback that if we were to include a message 
then it needed to be complete. (This seems to be some sort of policy 
based on the assumption that implementors will assume any message they 
find in a document can be used as a template for their implementation.) 
So, when messages are included they have a lot more detail than is 
needed for this purpose.

Do you think it would be better to enhance the "single line summary" 
currently being used so that it can carry all the relevant info?

>  transaction at the UAS and UAC."

This will be addressed in responses to Dale's comments.

>   exhort them NOT to do this.

I think adding a reference to Appendix A here would be helpful.

However I would like to defer to Appendix A for the qualification of 
pros and cons. This is not *always* the wrong thing to do.

>   ACK from the UAC was lost, the UAC will see a retransmitted

Most of the time this kind of problem won't occur. Requiring a delay 
would seem to be an inconvenience for the implementor, and likely to be 
ignored. Also, I think you need to wait considerably longer to 
*guarantee* that this problem won't occur. If you don't have that 
guarantee than you need to implement this recovery in any case.

>   sending a BYE, they see a retransmitted 200 OK (INVITE)?

There's a lot of weird stuff out there. I'm not sure about this specific 
case, but I have seen some similar things happen.

>   generated a final response.)

Perhaps its not strictly a "race" in a correctly written UA. But the 
point of this document is to clarify what it takes to correctly 
implement a UA that handles these unusual cases. Perhaps we should 
rename the document.

I think it is clear that there are plenty of implementations that don't 
retain dialog state after sending a BYE. This is useful information to 
indicate that they need to.

>  "What is established by SIP."  Please elaborate.

Well, I'm not sure. I will defer to Miki on this.

I know he wanted to put these in a different section because he felt 
they were of a different character than the others.

>   the BYE in such cases until the re-INV transaction has finished?

I guess we could do this if we want to revise 3261 to require this. If 
not, then this is legal and its helpful to point out the implications.

>   the INVITE transaction and the CANCEL itself should be answered by

Yes. This continues to come up on the list. So its good to repeat the 
mantra as often as possible.

>   gets a final response, the tag in the To will not match any of

I've mixed feelings about whether this is sufficiently relevant to 
include here or not.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 21 May 2007 08:37:32 -0500

> Thank you for the careful review. Comments inline.

Paul: Thanks for your feedback.  More inline.

> same place, without mentioning 4235, right?

Yes.  The state machines I provided do not have any bearing on
rfc4235; they pertain to the early dialog text in rfc3261 only.

> But ultimately I can go either way.

You have to consider who is the primary audience of this draft.
It will be new implementers and those implementers who want to
resolve some ambiguity when they observe something that does not
appear to be right.  Not all of these folks will be so steeped in
SIP lore and IETF that they will know to download the hitch-hikers
draft and see which RFCs make up the core SIP specification (rfc4235,
unfortunately is not a "core SIP" draft.)  For those who are not
aware of rfc4235, not only will they need to study it (in addition
to rfc3261), but they may also need to scan rfc3265 to understand
the event notification plumbing behind rfc4235.

Thus, self-containment is a good aim to shoot for.  This I-D is
attempting to tease out the ambiguities in rfc3261, not rfc4235.
Why burden implementors with more documents to read?

> think this is appropriate.

I will leave this up to you; any resolution is fine with me.  I
have seen Informationals contain normative text.  It's just that
normative text in a non-standards track is distracting.

> find in a document can be used as a template for their implementation.) 

OK; so we can expect to see "Content-Length: ...\r\n" soon?  Just
kidding.  Yes, I know that policy, but I hope that is more for
the sake of completeness than it is for use as a template.

> currently being used so that it can carry all the relevant info?

Given what you wrote above, it maybe sufficient to just warn the
reader that the call flows intersperse single line summary with
detailed messages.  Also explain why there is a need for the detailed
messages (presence/absence of SDP, etc.) at certain times and why
you choose a single line summary at other times.  That should do it.

> pros and cons. This is not *always* the wrong thing to do.

Hmm ... when would sending a BYE on an early dialog be the right
thing?  Early media?  That is the only case I can think of.  Are
there others?  Right now, the draft takes a position that even
though rfc3261 allows a UAC to send a BYE, it is not recommended
that UACs do so.  In other words, I do not remember Appendix A
providing any advantages of sending a BYE in an early dialog.
If early media is the only one, then Appendix A can include a
discussion of the pros and cons.

> ignored. 

I don't understand.  How inconvenient is it to set one extra timer?
If the user pressed the "Hold" button and the UAC has just sent out
an ACK, it can easily set a timer to wait for some time before
sending out the re-INV.

> Also, I think you need to wait considerably longer to 

Look at it this way: if the ACK from the UAC got lost, then
why won't the re-INV share the same fate?  Physical layers in
networks today are less susceptible to packet loss, and dropped
packets are the exception, not the norm.  Given this, the fact
that the ACK was lost may signify a congested network or an
overloaded router, and the chances are pretty good that the
re-INV will be lost as well.  Thus, it may actually help to
wait a bit before sending more traffic in the form of a
re-INV.

If the network is functioning normally and did indeed drop
an ACK as an exception, then the UAC should get a retransmitted
200.  If OTOH, the network is misbehaving, then the lost ACK may
be the first symptom of a larger problem.

As a reviewer, I felt that we are implicitly assuming that the
re-INV has some magical properties that will allow its fate to
be better than that of the ACK before it.  That may not always
be the case.  You could always mention delaying the re-INV as
a potentially a second solution to the problem.

> case, but I have seen some similar things happen.

OK.

> indicate that they need to.

OK.

> Well, I'm not sure. I will defer to Miki on this.

OK.

I will leave the text below intact for context.  Please see
my response after it.

> not, then this is legal and its helpful to point out the implications.

I don't follow: why would we need to revise rfc3261 to quarantine
a BYE?  RFC3261 does not say that an implementation MUST send a
BYE out as soon as the user associated with the phone hangs up.

In fact, decoupling the actions of the user from the actions of
the protocol is benefical.  In this particular case, only the
UAC's dialog/transaction machines knows the real nature of the
call -- the user has hung up, not caring whether or not the re-
INV succeeded.  Thus, the UAC's state machines can be more
judicious with the message spacing, making the life of the UAS's
transaction state machine much easier.

Also, just like in S3.1.4, we are implicitly assuming that the
BYE has some magical powers that will allow it to succeed when
the re-INV did not.  If the re-INV did not elicit a response
(maybe it got dropped), the chances are that the BYE will
suffer the same fate, is it not?

> mantra as often as possible.

OK; so I presume you'll add this in?  It'll be good to document
this mantra somewhere.

> I've mixed feelings about whether this is sufficiently relevant to 

I have encountered UAs that get upset when they see a new tag
in a non-2xx response.  The bar for documenting this right now
is low, and the payoff can be high.  I can send you the call flow
and the text.  I'll leave it up to you to decide.

Thanks.

- vijay