Subject: [Sipping] RE: Commentary on draft-niemi-sipping-event-throttle-reqs

From: [email-masked]
Date: Tue, 6 May 2003 13:03:30 +0300

Hi Dean,

Thanks a lot for the comments. I'll have some answers inline, and will edit the draft to also reflect your suggestions.

 > -----Original Message-----
 > From: ext Dean Willis [mailto:[email-masked]]
 > Sent: 25 April, 2003 04:56
 > To: [email-masked]; Niemi Aki (NMP/Helsinki)
 > Cc: [email-masked]; David Oran
 > Subject: Commentary on draft-niemi-sipping-event-throttle-reqs
 > 
 > 
 > 
 > At the last meeting, we agreed (well, actually Rohan 
 > volunteered us) that we
 > would look at the event throttling requirements draft, and 
 > that at least a
 > couple of us would post discussions before we considered 
 > taking it on as a
 > WG effort. So here's my try at it.
 > 
 > The given draft is:
 > 
 > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event
 > -throttle-reqs-
 > 01.txt
 > 
 > 
 > Overall, I think that developing an event throttling 
 > mechanism is a good
 > idea, and that this draft is a reasonable start on the requirements.

Good.
 
 > General comment: The draft seems to confuse the maximum 
 > notification rate
 > "desired" or "allowed" by the subscriber with the rate 
 > "required" by the
 > notifier. I'll come back to this at several points in the 
 > discussion. There
 > also seems to be a bit of confusion on the difference 
 > between average rates
 > and minimum interval -- they're not exactly inverses of each 
 > other. English
 > is such a fun language -- too bad it doesn't work well for 
 > specifications.

Good point. That certainly wasn't the intention. Simply without the require/allowed/desired semantics, a rate is the inverse of time and that was supposed to be the extent of it, and even that proved confusing... ;)

I'll try to clarify the language in the next version.
 
 > Section 3: Event Throttle Model
 > 
 > This section raises two throttling models, which it 
 > identifies as "strict"
 > and "leaky bucket" quarantines. 
 > 
 > The usage of the "strict" model should be clarified as 
 > establishing the
 > minimum time period allowed between two notifications.

I'll add text to that. 

 > The 
 > draft says that
 > the choice of which notification is sent is implementation dependent,
 > although it seems to assume a "newest" notification, where "newer"
 > notifications replace "older" ones if the minimum 
 > notification interval time
 > has not elapsed. I suspect that this replacement model has a 
 > lot of overlap
 > with filtering. Should we explicitly include a requirement that the
 > replacement policy be describable in the subscription process?

The draft actually tries not to make that assumption (but fails obviously ;). It lists as examples the replacement you also mention, as well as a merging of notifications. 

But I don't quite understand how this would overlap with filtering, as it is internal to the notifier, and depends on the type and contents of a notification, e.g., is it stateless or stateful? I think adding a requirement that the subscriber needs to be able to dictate the policy regarding the treatment of notifications in the queue would actually create that overlap.

In this case I would rather view filtering orthogonal to throttling.
 
 > This section also refers to what it calls a "leaky bucket 
 > style algorithm",
 > which is probably a misnomer. Traditionally (at least in my 
 > pointy head) a
 > "leaky bucket" refers to a FIFO queue with a variable 
 > arrival rate and a
 > fixed departure rate. There might be input "bursts" at a 
 > rate higher than
 > the output rate, resulting in a lengthening of the queue, 
 > but the output
 > rate is held constant as long as the queue length is 
 > non-zero. However, the
 > policy described in the draft is one of rate-averaging, 
 > which is something
 > like a leaky-bucket that kicks in only if the sliding-window 
 > average rate
 > exceeds the prescribed maximum. This could use some cleanup. 

Agreed. My treatment of queuing theory was obviously a bit rusty. ;)
 
 > Additionally, one might envision a rate-averaging queue that 
 > enforces its
 > operation by discarding or combining notifications instead 
 > of delaying them.

This is what the leaky-bucket was supposed to describe. Will change the draft to reflect this.
 
 > So basically, there are two queue models proposed: 
 > 
 > 1) minimum fixed interval or period between notifications, where the
 > interval can be described as a time value like 5 seconds. 
 > This can also be
 > described as maximum fixed rate, or notifications per unit 
 > of time, like 0.2
 > notifications per second or 1 notification per 5 seconds 
 > (oddly enough, this
 > is the reciprocal of the minimum interval)
 > 
 > 2) minimum average interval or period between notifications, 
 > which is better
 > described as the maximum average rate of notifications and 
 > best described in
 > notifications per unit of time, averaged over some time window.

Agreed.
 
 > And two reasonable queue-servicing policies:
 > 
 > 1) Delay notifications in a FIFO manner to conform to policy.
 > 
 > 2) Discard out-of-profile notifications or combine them with other
 > notifications to result in a notification stream that 
 > conforms to policy.

Agreed.
 
 > Note that policy 1 can result in increasing queue depth if 
 > the arrival rate
 > persists in exceeding the departure rate. Consequently, 
 > practical systems
 > using 1 are likely to revert to 2 at some point. Efficiency 
 > may also be
 > improvable by using a quenching mechanism to reduce the arrival rate.

Right, and also a variable rate policy would be likely to employ both 1 and 2 to achieve the rate averaging queue.
  
 > Section 4, Example Use Case:
 > 
 > This doesn't really describe a use case, but just presents 
 > us with the
 > mathematical notation of the reciprocal relationship between 
 > frequency and
 > period. Useful background, but a real use case (with actors, 
 > etc.) would be
 > nice here too. 
 > 
 > Perhaps something like:
 > 
 > Case 1: Alice subscribes to the status of Bob. Bob's status 
 > is served by
 > server S. Alice tells S (subscribes with a notification 
 > throttling policy)
 > that she wishes to receive notifications no more frequently 
 > than once every
 > five seconds. Bob publishes a status of Red to the server S, 
 > which notifies
 > Alice. 
 > 
 > Sub case a: After a delay of three seconds, Bob publishes a 
 > status of Green
 > to S. S, which implements a policy of discarding out-of-profile
 > notifications, stores the status of Green but does not 
 > notify Alice. After
 > three more seconds, Bob publishes a status of Blue to S. 
 > Since six seconds
 > have elapsed since the last notification to Alice, S 
 > notifies Alice that
 > Bob's status is now Blue. Note that in this sub-case, Alice is never
 > notified that Bob's status was Green, but the notifications 
 > that she does
 > receive are timely.
 > 
 > Sub case b: After a delay of three seconds, Bob publishes a 
 > status of Green
 > to S. S, which implements of policy of delaying 
 > out-of-profile notifications
 > so that they become compliant, stores the status of Bob. 
 > After two more
 > seconds, S notifies Alice that Bob's status is now Green. 
 > One second later,
 > Bob publishes a status of Blue. Again, S stores the new 
 > state for Bob, but
 > does not immediately notify Alice. Four seconds later, S 
 > notifies Alice that
 > Bob's status is now Blue. Note that in this sub-case, Alice 
 > is notified of
 > all statuses published by Bob, but often has a different 
 > understanding of
 > Bob's status than does Bob, because the notifications from S 
 > to Alice are
 > delayed.

I will add such a use-case to the draft.
  
 > REQ3: 
 > 
 > Says that "The notifier must be able to indicate that it 
 > does not support
 > the use of a throttle mechanism in the subscription. This 
 > would be better
 > worded as ". . . for a specific subscription", otherwise 
 > we'll have people
 > thinking "in the subscription" means "in the SUBSCRIBE", 
 > when we all know it
 > would have to be "in the response to the SUBSCRIBE".

Fixed.
 
 > REQ6: 
 > 
 > Ends in "For example, local policy could dictate an even 
 > lower rate of
 > notification than what the subscriber requires." Refer back 
 > to my General
 > Comment earlier in this missive. It seems to me that this 
 > would be better
 > worded as " . . . what the subscriber allows". I think we're having a
 > tendency to get confused about what the rate limit is asking for. The
 > subscriber is saying "I want to receive notifications no 
 > more frequently
 > than once per X seconds", not "You MUST notify me EVERY X seconds."

Good point. The intention was definitely not "MUST notify every X seconds". Will fix the wording.

 > REQ7:
 > 
 > Says that security mechanisms "SHOULD be applied to 
 > subscriptions . . . ".
 > This is trying to define operational guidelines at protocol 
 > requirements
 > time. Rather, we should word this sort of thing to require a 
 > capability to
 > be met by the mechanism to be developed. Perhaps "A throttle 
 > mechanism MUST
 > allow for the application of authentication and integrity protection
 > mechanisms to subscriptions invoking that mechanism."

Sounds all right to me.
 
 > 
 > Section 6: Security Requirements
 > 
 > Issue 1 points out that it might be possible for a 
 > subscriber to set a
 > maximum notification interval longer than the subscription duration,
 > consequently resulting in only getting one notification per 
 > subscription.
 > Should we add a new requirement on the order of "A notifier 
 > receiving a
 > subscription request including throttling policy MUST be 
 > able to response
 > with something having the semantic of 'That's a really 
 > freaking stupid
 > idea'.? Or should we add a requirement more like "A 
 > throttling mechanism
 > MUST include discussion of the situation resulting from a minimum
 > inter-notification period which exceeds the subscription duration and
 > include mechanisms for avoiding this situation and/or guidance to
 > implementers on the dangers of getting exactly what they asked for"?
 > 
 > Issue 2 raises the possibility that a subscriber might set a 
 > very short
 > minimum inter-notification period (or very high maximum 
 > notification rate),
 > thereby causing the notifier to exhaust itself sending at 
 > that frequency.
 > This is, well, bogus. As I pointed out above, the throttling 
 > policy does not
 > tell the notifier the rate at which notifications should be 
 > sent. Rather, it
 > tells the server the rate that notifications must not exceed. This is
 > something like a traffic sign. If the sign on the street 
 > says "Speed Limit:
 > 30 kph", this does not force all cards to speed up to 30 kph. In most
 > situations (barring a few large motorways that have a 
 > SEPARATE policy for
 > minimum speeds) driving at 28 kph, or even 20 kph, would be 
 > just fine.
 > 
 > Conclusion: Note that there is considerable potential for 
 > confusion between
 > frequency (or rate) and period (or interval) in this 
 > conversation. We should
 > be careful to say explicitly what we mean. Is it feasible to 
 > use just one
 > term in all discussions? 

Yes. I would propose that the model only talks about queues at the notifier, and minimum intervals set by a subscriber.

 > I have the feeling that SIP is not 
 > likely to be
 > well-suited to exceptionally frequent notifications. Is it 
 > reasonable to
 > state a minimum period in seconds? This lets us use a 
 > signed-16 range to
 > express inter-notification periods ranging from 1 second to 
 > a little over 9
 > hours. Do we need higher resolution than that? There's 
 > probably a resolution
 > requirement that needs to be stated in this draft.

This is probably reasonable, although a little bit into the implementation space. At some point I entertained the thought (I think Hisham suggested it), but didn't find a proper wording for such a requirement. But I'll try to come up with something proper, unless you have some text to suggest?

Cheers,
Aki
 
 > --
 > Dean
_______________________________________________
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