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

From: Jun KOSHIKO <[email-masked]>
Date: Mon, 11 Jun 2007 12:02:20 +0900

Hi Vijay,

Sorry for late reply.
Now, I am just going to update the draft based on the comments.

On two points, I would like to confirm your idea
about how I should reflect your comments in the document.

Inline.

> Paul Kyzivat wrote:
> > Vijay,
> > 
> > Thank you for the careful review. Comments inline.
> 
> Paul: Thanks for your feedback.  More inline.
> 
> > If I understand, you are simply proposing a different way to get to the 
> > 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.
> 
> > 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.
> 
> 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?
> 
> >> 4)  This is a BCP, right?  If so, I find the normative text a bit
> >>   distracting.
> > 
> > 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.
> 
> 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.
> 
> > 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.) 
> 
> 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.
> 
> > 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?
> 
> 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.
> 
> >> 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.
> > 
> > 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.
> 
> 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.
> 
> >> 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.
> > 
> > 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. 
> 
> 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 
> > *guarantee* that this problem won't occur. If you don't have that 
> > guarantee than you need to implement this recovery in any case.
> 
> 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.

The proposed solution which is "wait for T1*2 or T1*3 seconds" may be
effective when a network becomes instability for a short time.
However, the following new issue arises.
"How many seconds is the optimal waiting time for implementors?"
In this document, I would like to show the appropriate handling of
the race condition which arises even if the implement is good enough,
rather than discussing what is the best implement.

> >> 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)?
> > 
> > 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.
> 
> OK.
> 
> > 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.
> 
> OK.
> 
> >> 7)  S3.3 - I am not sure what the authors mean by the phrase
> >>  "What is established by SIP."  Please elaborate.
> > 
> > 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.
> 
> >> 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.
> > 
> > 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.
> 
> 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?

Appendix B was written responding to the question on sip-implementors ml.
The question at that time is the following two affairs.
1. Can UA send a BYE when it receives no response to re-INVITE?
  -> Yes. RFC 3261 doesn't restrict it.
2. How is re-INVITE processed when UA sends BYE?
  -> Every transaction completes independent of others.
     (It means that re-INV is processed like any other case.)

In such a situation, it may be good to recommend the implement that UA
quarantines the BYE until a response to the re-INV has been received.
However, since RFC3261 allows UA to send BYE without waiting a response
to re-INVITE, I would like to show by Appendix B that "every transaction
completes independent of others" even in such a case.

It may be repetition of the reply in 4), but I would like to show the 
appropriate handling of the race condition which may arise, rather than
arguing what is the best implement.
 
Thanks,
Jun

> >> 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.
> > 
> > Yes. This continues to come up on the list. So its good to repeat the 
> > mantra as often as possible.
> 
> OK; so I presume you'll add this in?  It'll be good to document
> this mantra somewhere.
> 
> >> 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.
> > 
> > I've mixed feelings about whether this is sufficiently relevant to 
> > include here or not.
> 
> 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
> -- 
> 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

-------------------------------------------------
Jun KOSHIKO

Next Generation Network Strategy
Research and Development Center
NTT East Corporation

Telehone   +81 3 5359 5104
Facsimille +81 3 5359 1236
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
-------------------------------------------------

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 11 Jun 2007 16:04:33 -0500

> about how I should reflect your comments in the document.

Sure.

> "How many seconds is the optimal waiting time for implementors?"

How long to wait does not have a simple answer, unfortunately.
TCP, for instance, monitors normal exchange of data and develops
and subsequently fine-tunes the RTT.  When SIP is used over UDP,
we do not have such fine-grained mechanisms and instead rely on
T1 firing.  However, if all this was not complex enough, I know of
implementations that make the value of T1 configurable at run-time
depending on the network characteristics.

So ... I would say that something like

   unsigned int temp_T1 = T1;
   ...
   temp_T1 = T1 < 500 ? 500 : T1;

   delay(MIN(temp_T1*3, 2000)); /* interpreted in ms */

is appropriate, and the delay has an upper bound of 2s (which I
think is better than the alternative.)  If the network is
indeed congested, then sending a re-INV will not help it anyway.

> rather than discussing what is the best implement.

Best to implement from what point of view?  Network health?  Or
programming complexity?  Clearly, trying to avoid programming
complexity will lead to unnecessary bandwidth on the network.

I think a good medium is to simply mention in S3.1.4 that a robust
implementation may introduce slight delay (MIN(T1*3, 2000)) between
F4 and F6.  Those programmers that are not afraid of complexity
will code in this delay; those that do not want to deal with the
additional complexity will disregard it and simply burden the
network with additional traffic that may well suffer the same
fate as the ACK.  But at least the pros and cons of the solution
are presented to the implementor.

> completes independent of others" even in such a case.

Much as you have taken pains to decouple the transaction state
from the dialog state, I believe you ought to do the same and
decouple the user behavior from the dialog behavior.

Nowehere in rfc3261 does it say that the BYE must be sent out
immediately when a user hangs up (it does say that a BYE must be
acted on immediately when received, but that is a different
case.)  Now, in practical terms what this means is that if a
user pressed the "Hold" button and then immediately pressed the
"BYE" button, the dialog layers will get two messages in sequence:
re-"INV" and "BYE".  The dialog layer have already sent the
re-INV out, and it knows that the user has hung up because the
next message it received was BYE.  So it is trivial for the
dialog layer to hold on to the BYE until it has gotten a final
response for the re-INV.  This short buffering will save an awful
lot of protocol complexity.

> arguing what is the best implement.

Again, best to implement from what point of view?  Certainly, a
bit of buffering saves the network from excessive messages and
does the same for the receipient, who does not have to grind
protocol machinery more than absolutely necessary.  Conscientious
implementations may implement such a buffering if they are
made aware of it; those that do not want to deal with this
additional complexity imposed from buffering will, ironically,
have to deal with yet more complexity in the form of a
convoluted protocol flow.  But let's leave that choice to the
implementation -- our job is to provide the choice in the
first place.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2007 09:43:39 -0400

Vijay,

Your questions are good, in that they expose different ways to think 
about this.

IMO we must consider independently the senders and receivers of requests 
and responses. A sender of a message may use some discretion about when 
to send it. (With some limits imposed by the protocol.) But a receiver 
of a message has no control over when it will be received. A message may 
arrive at an inconvenient time, when there are issues about how it 
should be processed.

We can recommend policies for the sending of messages that may mitigate 
race conditions for the receiver of those messages. But in many cases we 
cannot mandate that those policies be followed. So it is still good to 
clarify the handling of messages that happen to arrive at times, and in 
orders, that may be confusing or difficult to handle.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 12 Jun 2007 09:10:41 -0500

Paul Kyzivat wrote:
> IMO we must consider independently the senders and receivers of 
> requests and responses. A sender of a message may use some discretion
> about when to send it. (With some limits imposed by the protocol.)

Absolutely.

> But a receiver of a message has no control over when it will be 
> received. A message may arrive at an inconvenient time, when there 
> are issues about how it should be processed.

Sure; but I believe that if implementers are made aware of
techniques to lessen the impact on excessive griding of protocol
machinery, some may actually implement them.  In the absence of
such guidelines, implementations will become excessively
aggressive in sending messages under adverse network conditions.

The thing we have to keep in mind is that not every developer
appreciates -- or is even aware of -- the real-time nature of
developing network protocols, the race conditions and nuances
that it entails, and the impact of a protocol action on the
network bandwidth and usage.  Since the SIP protocol is being
developed by implementors with a wide latitude in experience, a
bit of clarification goes a long way.

> We can recommend policies for the sending of messages that may 
> mitigate race conditions for the receiver of those messages. But in 
> many cases we cannot mandate that those policies be followed.

Agreed.

> So it is still good to clarify the handling of messages that happen
> to arrive at times, and in orders, that may be confusing or difficult
> to handle.

Absolutely.  Don't get me wrong -- I am not saying that you
should scrap out the resolutions you have in S3.1.4 and Appendix
B.  The worst-case way to resolve these race conditions stays as
specified in the draft; my point is that we ought to provide some
hints to the reader (who we are assuming *is* a developer) that
here is a way to lessen the impact on the receiver.  Then, leave
it to the reader to implement the code as they see fit.

Thanks.

- vijay

---

From: Miki HASEBE <[email-masked]>
Date: Mon, 25 Jun 2007 16:27:34 +0900

Hi Vijay,

I apologize for the late reply.
I understood your proposal.

I think you are quite right about suggesting that it will be
beneficial for implementors to provide some hints to
avoid race conditions.
I would like to add some text to the draft based
on your comment.

Although I think your proposed condition for implementation,
waiting for 2 seconds at most, works in most cases,
I am concerned that discussion may arise on the validity
of waiting time, etc.
Such discussion about the validity of the implementation
is not a target of the draft.

Therefore, I would like to add a note to say that it is
one of the possibilities of implementation and is guiding
information to avoid the race condition.

On the other hand, if you think it is needed to facilitate
discussions on appropriate implementations for avoiding
race conditions or other problems, it might be good to produce
a new draft as an implementors guide.

I intend to add a note as guiding information,
but please let me know your opinion on this idea.

Thank you.