Hi Brian, Please find below some comments/questions marked with [KK] on your review comments (some of my comments were also taken into account when we updated the draft from -07 to -08) Thanks for the review! Krisztian -----Original Message----- From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of ext Salvatore Loreto Sent: Tuesday, February 17, 2009 4:09 AM To: Rosen, Brian Cc: sipping@xxxxxxxx Subject: Re: Review of draft-niemi-sipping-event-throttle-07 Hi Brian and all, thanks for the review. see my comment/answers in line /Sal Rosen, Brian wrote: > 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. > [Sal] yes, it is applicable to both you are right, so I propose to change the text as follow: These mechanisms are applicable to any event subscription, both to a single event subscription and to a event 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? > [Sal] not really, the two sentences describe the behaviour of the two sides, the Notifier and the Subscriber. The second statement in particular describe the possibility for the Subscriber (the Tracking application) to modify the average interval and doing so force the Notifier to recalculate the maximum time allowed between two subscriptions. So I propose to change the second statement in the following way: The tracking application can also modify the average interval during the lifetime of the subscription by setting the event average extension to a different value. > 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 > [Sal] right I'll change them in: REQ1: The subscriber must be able to set the minimum time period (throttle) between two notifications in a specific subscription. REQ2: The subscriber must be able to set the maximum time period (force) between two notifications in a specific subscription. > In REQ 5, would "any event" be better than "all events"? > [Sal] OK REQ5: It must be possible to use of the throttle, force and average mechanisms in subscriptions to any 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" > [Sal] OK REQ6: It must be possible to use the throttle, force and average mechanisms together with any other event filtering 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. > [Sal] Not really, as you pointed out the idea behind this requirement is that the notifier should be able to increase it, if necessary. So maybe it should be better change the word "adjusted" in "increased" [KK] It think "adjusted" was correct as the notifier may lower the throttle value in case it is conflicting with the subscription expiry time. The same is also said in another comment from you (copied here): Brian> In 4.3, perhaps you should mention that if the subscriber requests a Brian> min greater than the subscription expiration, the notifier should Brian> change the throttle to the expiration time left. REQ7: The notifier must be allowed to use a throttling policy in which the minimum time period between two notifications is increased from the value given by the subscriber. For example, due to congestion reasons, local policy at the notifier could temporarily dictate a throttling policy that in effect increases the subscriber-configured minimum time period between two notifications. > 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". > [Sal] I propose to change REQ8 in REQ8: The throttle mechanism must discuss corner cases for setting the minimum period between two notifications. At a minimum, the throttling mechanism must include discussion of the situation resulting from a minimum time period which exceeds the subscription duration, and should provide mechanisms for avoiding this situation. > You might be better to continue to use the word "modify" instead of > "adapt" in REQ9. > [Sal] yes I agree. REQ9: A throttle, force and average must be possible to be installed, modified, or removed in the course of an active subscription. > 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. > [Sal] thanks, I'll insert the suggested text. > 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. > [Sal] we say that the buffer policies depend on the mode in which the notifier is operating. So it is how the notifier has been setted. [KK] I am not sure what are the two policies. I think the policy is that the throttle is effective on the list subscription itself (what is the other policy?). Whether the RLS propagates the throttle to back-end subscriptions or not is up to the RLS depending on the size of its buffers, I guess. > 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. > [Sal] it is only for the throttle mechanism. So I propose: 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. However if a local policy at the notifier can not meet the requested throttle values, then the notifier can increase opportunely the received value. [KK] I think "adjust" is the correct word here due to the reason discussed above. > 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. > [Sal] we do not say "no sense" we say little sense, that means that there could be corner case where they can be used together. I propose to add the following test: Force and Average: as both the parameters are designed to force an update, this combination makes sense only in some corner cases. A subscriber SHOULD choose a "force" value higher than the "average" value, otherwise the notifier MUST not consider the "force" value. > 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. > [Sal] that is a general discussion. The time in all the Event packages is always calculate in *integral* seconds. So a modification would have a general impact. [KK] For presence, I think integral seconds are just fine. For location, tenths of a second is probably necessary/useful. Do you have a suggestion from GEOPRIV viewpoint? > 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. > [Sal] the section already has some text about it. "The notifier is responsible for adjusting the proposed throttle value based on its local policy or other properties. The notifier MAY lower the throttle value, e.g., because of lowering the subscription expiration. The notifier MAY also choose a higher throttle value, e.g., because of static throttle value configuration given by local policy. The notifier MUST include the adjusted throttle value in the Subscription-State header field's "throttle" parameter in each of the NOTIFY requests. In addition, different event packages MAY define additional constraints to the allowed throttle intervals. Such constraints are out of the scope of this specification." > 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? > [Sal] exactly the formula is used to vary the absolute pacing in a way that will meet the average requested 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. > [Sal] yes that is exactly what the timeout is. I'll use your definition! > 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. > [Sal] right. I don not have any objection to remove the reference to RFC3261 > Brian > > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use > sip@xxxxxxxx for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
