Draft:   draft-niemi-sipping-event-throttle-07
Reviewer: Brian Rosen
Review Date: 29 January 2009
Review Deadline: 
Status: Pre-WGLC

Summary: I have reviewed this draft.  I think this is a very worthwhile mechanism, and the draft is getting mature; more than enough to warrant advancing it to (some) work group item.

My comments:
-------------

In section 1:
   These mechanisms are applicable to any event subscription, but the
   throttle mechanism is mainly intended for use with an event list
   subscription.

Why is this?  Seems to me that throttle is as applicable to a single event subscription as it is to a list subscription.

   The average rate control allows the notifier to dynamically increase
   or decrease the Notification frequency.

   The tracking application can also modify the average during the
   lifetime of the subscription.

Don't these two sentences say the same thing?

The wording of REQ 4 is awkward because in REQ1-2, you don't name the mechanisms (throttle, force), but then you use the name in 4.  Perhaps 1 is reworded:

   The subscriber must be able to set the maximum time period (throttle)
   between two notifications in a specific subscription.

and a similar change in REQ2

In REQ 5, would "any event" be better than "all events"?

In REQ 6, might you add the word "other" so that it reads "together with any other event filtering mechanisms" and note the plural on "mechanisms"

In REQ 7, do you really want to give the notifier the right to decrease the minimum time?  Seems like it should only be able to increase it.  We should allow the notifier to increase the maximum time; if the subscriber asks for 10 sec max, but the notifier is only able to do 20 sec min, it has to increase it.

I am unhappy with the wording of REQ8.  I don't know what "reasonable resolution" is supposed to mean.  Perhaps you want to talk about "corner cases".  I'm not even happy with that, but it's better than "reasonable resolution".  

You might be better to continue to use the word "modify" instead of "adapt" in REQ9.

I find the introduction to 3.5 to be lacking.  Perhaps something along the lines of:

   When applied to a list subscription, the event throttle mechanism has

   some additional considerations.  Specifically, the throttle applies to 
   the aggregate notification stream resulting from the list subscription, 
   rather than explicitly controlling the notification of each of the 
   implied constituent events.

Having said that, we may also want to observe that the list event notifier can use the throttle mechanism on its own to control the rate of the individual subscriptions to avoid overflowing its buffer.

Also in 3.5, you leave the notion that there are two policies without any notion of whether it's just a choice of the notifier, or the subscriber can influence the choice of policy.  Since this is not mentioned anywhere else I could spot, I'm guessing that the notifier decides itself and tells no one.  We at least ought to say that, and consider whether the subscriber should be able to ask for one policy or the other.  Maybe I'm missing something.

In the 3.6 discussion, this para:
   A notifier that supports the throttle, force and average mechanisms
   will comply with value given in the throttle, force and average and
   adjust its rate of notification accordingly.
doesn't discuss the notion that the notifier can change the values if it can't meet the requested values.

In 3.7, I am not so sure that the last two combinations make no sense.
The average is a statistical calculation which varies slowly over time.
The max and min are instantaneous limits.  It may very well be appropriate to, for example, say "send me notifications with an average of 1/sec, but send me at least one every 3 sec".  See my discussion on the average formula below.

In 4.2.1, I want to open a discussion of whether integral seconds is sufficient.  I would think at least tenths of a second, if not finer grain is needed.

In 4.3, perhaps you should mention that if the subscriber requests a min greater than the subscription expiration, the notifier should change the throttle to the expiration time left.

In 6.2, The formula implies a fixed pacing: it gives an absolute value for the next interval.  Could we not say that the formula produces an ideal pacing, but he notifier can vary the absolute pacing to achieve a moving average that achieves this result over the period?

The usual formula for a the mth interval in a moving average of n samples is 
          I + I + ... + I
           m   m-1       m-(n-1)
average= -------------------
                  n

Then, perhaps you want to define the term "timeout" by changing the sentence after the formula to:
   The output of the formula, "timeout", is the time to the next notification, 
   expressed in seconds.

In 7.2 I don't understand the reference to RFC3261.  We only want the parameters allowed in the Subscribe and the Notify, not in any other message.