Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03

[Janet P Gunn <[e-mail]>]

I have some further comments, mostly about the "average" mechanism.

While “max-interval” is synonymous with “minimum rate”, and “min-interval” 
is synonymous with “maximum rate”, the constant switching back and forth 
between the two sets of terminology makes it very difficult to follow.

Pick one set, and use that as the dominant term.  At a minimum, the 
section heading should be consistent.

The description of the intended effect of the “average-interval” is 
unclear and inconsistent.

In the introduction, it says 
“   average-interval:  specifies an average cadence at which notifications 
are desired, in seconds.”

This implies that it will speed up the rate of notifications when they 
would otherwise be too slow, and slow them down when they would otherwise 
be too quick.

Later in the intro it says 
“All those mechanisms are simply timer values that indicates (sic) the 
minimum, maximum and average time period allowed between two 
notifications. As a result of those mechanism, a compliant notifier will 
adjust the rate at which it generates notifications.”

This also implies that the “average-interval” mechanism will both speed up 
and slow down the rate, as appropriate.

In section 3.3, Use Case for specifying the average rate of notifications, 
it is contradictory.  First it says
“dynamically increases the interval between notifications if the target 
has sent out several notifications recently.”  This is an INCREASE in the 
interval

But then it says
“The "average-interval" parameter value is used by the notifier to 
dynamically calculate the maximum time allowed between two subscriptions 
(sic).”
First, I assume you mean “between two notifications”. Not “between two 
subscriptions”.  But more importantly, dynamically calculating “the 
maximum time allowed between notifications” means that you will DECREASE 
the interval between notifications, if the target has not sent out any 
notifications recently.

And further
“This type of rate control allows the notifier to dynamically increase or 
decrease the Notification frequency.”

When we get to section 6 (Operation of the average rate mechanism), it 
starts off by saying 
“The main consequence for the subscriber when applying the average rate 
mechanism is that it can receive a notification even if nothing has 
changed in the current state of the notifier.”
This involves  a DECREASE in the interval.

I found the  use of the term “timeout”  confusing as it implies (at least 
to me) “a time in which you must not send anything” rather than “a time 
after which you must send something”- but maybe that is just me.

When we get to the formulae and the detailed mechanics, it is clear that 
this approach will only ever DECREASE the interval between notifications 
(from what it would be without Event Rate Control), it will never INCREASE 
the interval between notifications  (from what it would be without Event 
Rate Control).

So you need make the document consistent.  Either remove the text that 
says (or implies)  the “average-interval”  mechanism will increase, as 
well as decrease, the interval, or modify the mechanism so it DOES 
“dynamically increase or decrease the Notification frequency”. (the latter 
would be, I think, preferred).

Furthermore, in the description of the “average-interval” mechanism, there 
needs to be either a “MUST” or a “SHOULD” to ensure that “period” is 
GREATER THAN the “average-interval”.  Otherwise the described mechanism 
will send out a notification every “period” seconds, regardless of the 
value of “average-interval”.


Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

[e-mail] wrote on 06/10/2010 04:14:29 PM:

> [image removed] 
> 
> [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03
> 
> Robert Sparks 
> 
> to:
> 
> SIPCORE
> 
> 06/10/2010 04:14 PM
> 
> Sent by:
> 
> [e-mail]
> 
> Summary: This draft has a few adjustments that are needed before 
> moving it into IETF Last Call.
> 
> Major question:
> 
> Why isn't this an Update to 3265? Is there text here that prevents 
asubscriber
> from generating Event headers in 200 OKs to NOTIFYs mid-subscription 
(when he
> didn't probe for support using the SUBSCRIBE?) How would they know the 
request
> got honored?  The possibility of running into implementations that 
> break should
> be called out.  4.2 indicates the subscriber only gets a "hint" about 
support
> for rate-control in the notifier - is the condition it describes really 
only a
> hint?
> 
> In several places, the notifier is given permission to adjust an 
> interval based
> on local policy.  The document should be explicit about allowing 
theadjustment
> in any direction (increasing or decreasing) since there are so many 
other uses
> of intervals in SIP and SIP Events that allow adjustment only in 
onedirection.
> A few places I noted when reading the document were the Note in REQ7, 
4.3 4th
> paragraph, 5.2 paragraph 3, 6.2 paragraph 3.
> 
> The last paragraph of section 3.6 claims "exactly the same properties" 
except
> for being generated constrained to a schedule. Can you clarify 
whichproperties
> you mean? Many properties of the notifications beside their timing are 
clearly
> different (for instance, you may miss state transitions).
> 
> The security considerations section deserves more text: 
> * What is the forward reference from section 3.4 supposed to be pointing 
to?
> * Call out the implications on a Notifier having to store/aggregate 
> partial state
> * Note that the Event header (particularly in 200 OKs) is not 
> integrity protected. 
>   This would allow anything that could modify the message in flight (or 
an 
>   eavesdropper that could race a 200 OK in) to suppress (or flood) 
> notifications 
>   without the subscriber seeing what caused it.
> 
> The assertion that applying rate limiting and compression together 
results in
> savings as good as the sum of applying them independently should be 
supported
> or adjusted. I think it's sufficient to say they can be applied 
together.
> 
> Below are several suggestions for text tweaks. The first few (staring 
with *)
> are the most important. 
> 
> * Section 3.2 paragraph 4: suggest replacing "does not typically" 
> with "may not"
> 
> * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter 

>       indicates ... complete state information' is difficult to 
> parse. Could it
>       be simplified?
> 
> * Section 4.3 first paragraph, last sentence: "For such cases" is 
ambiguous.
>   Suggest "If the min-interval value is greater than the subscription 
expiry".
> 
> * Section 6.2 last paragraph: This currently says the timeout mechanism 
does
>   not affect when 3261 transaction retransmissions are generated. It 
should
>   also explicitly note that retransmissions do not affect the 
calculation of
>   the next timeout.
> 
> Introduction, paragraph 2: suggest replacing "congestion" with "load"
> 
> Section 3.1  paragraph 3: suggest replacing "amount of traffic" with 
> "number of notifications"
> 
> Section 3.5 paragraph 1: Suggest a reference for RLS after "list 
> subscription".
> The sentence "Moreover, the list event notifier..." should be more 
explicit
> about using the rate mechanism for any back-end subscriptions it might 
have.
> 
> Suggest referencing 3261 in the last paragraph of 4.2
> 
> Section 4.3, 3rd paragraph last sentence. The only way the subscriber 
_can_
> resume notifications is to renew the subscription with a resubscribe 
request.
> Would this text work? "This results in receiving no further 
> notifications until
> the subscription expires or the subscriber sends a SUBSCRIBE 
requestrefreshing
> the subscription (perhaps resuming notifications)".
> 
> The text needs to be adjusted to reflect subnot-etags being issued as an 
RFC
> 
> Adam suggested some RFC-Editor notes in the proto writeup (which may 
address
> some of the above comments). Please be sure to incorporate those when 
revising
> the draft.
> 
> One last question:
> 
> If the combination of min-interval, max-interval, and average-interval 
make
> little sense, why does the document allow them to be combined? I 
> think what the
> group was trying to say is that we currently don't forsee a use for 
combining
> those options, but do not wish to forbid their combination.
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore