WSNP 4.11 (message rates) using burst/sustained approach

[Matthew I Roberts <matt.roberts@uk.ibm.com>]

All,

Following the conference call on 18th
July I had an action to recast the 'managing message rates' (WSNP 4.11)
policy option using the concept of 'burst' and 'sustained' speeds. I have
also been giving some more formalized thought to the use case(s) behind
this property in order to make sure that we are providing a useful configuration
option.

As always, comments gratefully received!
Cheers,

Matt


Matt Roberts
IBM WebSphere Messaging Design and Development
Hursley Park, England. +44 1962 815444
matt.roberts@uk.ibm.com
MP 211 / DE3H22



Use Case:
A consuming application is unwilling
or unable to process more than a specified number of NotificationMessage
elements in a given time interval. This might be because the processing
of a notification message on a lightweight consumer takes up all the available
processor cycles for a given period of time, or the device wishes to ensure
that there are free periods of time in which other processing can take
place (unrelated to notification messages that it may receive).

There are two patterns of application
of this type;
1. A simple (single threaded?) device
which is only able to handle one message at a time, and does not have the
resources to store a queue of messages ready for processing. This application
requires the ability to specify the frequency at which messages can be
delivered by the producer.
2. A similarly constrained device that
can only process one message at a time, but is capable of storing messages
on a temporary basis if they arrive while there is already a message being
processed.

These requirements are addressed respectively
by the "Sustained" and "Burst " pacing mechanisms described
below. An element 'messageRate' is defined with two attributes that allow
the application to configure its requirements;

wsnp:messageRate/@type
        Values
of "sustained" or "burst" indicating the way in which
the application wishes to define the rate.

wsnp:messageRate/@duration
        Values
of "second", "minute" (or "hour"?) -The time
interval over which the message rate should be measured

wsnp:messageRate
        Positive
integer indicating the number of notification messages that should be delivered
in the specified time interval (and in line with the specified type). Note
that the number of invocations that this number of messages relates to
is controlled using the boxcarring policy option from 4.10.


Sustained:
A consumer requires that NotificationMessages
are delivered at even intervals over a given time period - for example
a maximum sustained delivery rate of 5 messages per second implies an interval
of at least 0.2 seconds between each invocation.

In the case of a consumer that can only
process a single message at a time this policy option should be used in
conjunction with the property specified in 4.10 (Boxcarring) to ensure
that only a single notification message would be sent in any given invocation
of the Notify operation.

In the example below the consumer has
requested a sustained rate of 300 notification messages per minute - equivalent
to an interval of 0.2 seconds between each invocation if the boxcarring
option has been used to set the max batch size to 1.

  <wsnp:messageRate type="sustained"
duration="minute">
    300
  </wsnp:messageRate>


Burst:
The consumer is able to process a fixed
number of notification messages in any given time interval, but does not
need to be prescriptive about the timing with which those messages are
delivered, because it has the capability to store a set of messages if
there is already a message being procesed. For example a consumer that
is able to process 5 messages in a second might receive those messages
in a single invocation of the Notify operation (with 5 messages in the
batch), or five invocations of the Notify operation within the first 100ms
(and then nothing further for a while).

In the example below the consumer has
requested a burst rate of 5 messages in any given 1 second interval.

  <wsnp:messageRate type="burst"
duration="second">
    5
  </wsnp:messageRate>


A burst rate of 5 msgs/second is illustrated
in the ascii art below, where each column represents 0.1 seconds. Note
that counting the number of messages per fixed 1 second slice is not sufficient,
because a back-heavy second followed by a front-heavy second would result
in messages piling up faster than they can be processed.

|---------|---------|---------|---------|
     **** *    
 *  ****    * * *
  |---------
        |---------
           
     |---------
           
          |---------


Note that if the burst property and
boxcarring property are both specified, then the resultant maximum batch
size if the lower value of the boxcarring batch size and the burst size
(since delivering more than the burst size number of messages in one invocation
would contravene the burst property.


Questions:
* Is that the correct interpretation
of sustained and burst?
* Implementing a burst rate producer
isn't trivial - to do a proper job you have to consider a sliding window
rather than a fixed time slice
* Is the scaling appropriate? Are people
going to want a burst rate of 20 messages every 10 seconds, or is that
close enough to 2 messages every second?