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

From: "Dean Willis" <[email-masked]>
Date: Thu, 24 Apr 2003 20:55:32 -0500

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.

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.

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. 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?

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. 

Additionally, one might envision a rate-averaging queue that enforces its
operation by discarding or combining notifications instead of delaying them.

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.

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.

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.

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.

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".

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."

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."

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? 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.

--
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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 28 Apr 2003 16:31:50 -0400

Dean,

I would need to refresh my memory on this, but isn't the strict rate
mechanism just a sub-case of the leaky-bucket one, i.e. one where the
token bucket has a maximum size of one token?

I also have a serious case of deja-vu on the minumum server - maximum
receiver discussion.  Previous worked out protocols on this (related
to timers) should be re-used, no?

Mike

At 08:55 PM 4/24/2003 -0500, Dean Willis wrote:

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

The given draft is:

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.

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.

This section raises two throttling models, which it identifies as
"strict"

The usage of the "strict" model should be clarified as
establishing the

minimum time period allowed between two notifications. 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

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

Additionally, one might envision a rate-averaging queue that enforces
its

operation by discarding or combining notifications instead of delaying
them.

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

2) minimum average interval or period between notifications, which is
better

described as the maximum average rate of notifications and best described
in

notifications to result in a notification stream that conforms to
policy.

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.

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

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.

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

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."

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

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

inter-notification period which exceeds the subscription duration
and

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? 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

--

Dean

Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Apr 2003 20:31:45 -0500

> token bucket has a maximum size of one token?

You could look at it this way. Aki actually proposes that there may be 
some sort of status combiner or aggregator "in the bucket" that 
generates "new" presence information based on more than one input to the 
bucket, so this is a little different than a classic leaky bucket.

> receiver discussion.  Previous worked out protocols on this (related to 
> timers) should be re-used, no?

You mean the wildly successful session timer work? ;-)

--
Dean

---

From: Michael Hammer <[email-masked]>
Date: Wed, 30 Apr 2003 12:00:03 -0400

Dean,

Someone once defined insanity as repeating the same painful process and 
expecting a new outcome.  Do you expect a different outcome? :)

Mike

At 08:31 PM 4/29/2003 -0500, Dean Willis wrote:
>some sort of status combiner or aggregator "in the bucket" that generates 
>"new" presence information based on more than one input to the bucket, so 
>this is a little different than a classic leaky bucket.
>

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 30 Apr 2003 15:25:12 -0500

> expecting a new outcome.  Do you expect a different outcome? :)

Given that we are now in a state of either partial non-consensus or
confusion on the utility of the session-timer work, I don't really expect
different results but question whether that path can be expected to bear
useful fruit. Perhaps the path less-chosen will prove more useful, or at
least not so muddy.

--
Dean