NEW ISSUE: better support in handling space-greedy sequences

New issue as previously discussed, which does not address exactly the RM-Source-controlled option that Duane had in mind, but probably addresses part of the concern behind...

-Jacques

-----------------------------------------------------------------------------------------------------------------------------------------------

Title: better support in handling space-greedy sequences.

Description: In case an RM destination expects a large number of concurrent sequences, it may find itself in a position where maintaining the state of existing sequences takes too much resources. As a consequence, existing sequences may need to be terminated by the RM Destination, or new CreateSequence requests may be turned down, and denial of service occurs.

COnsider a rate of message loss (and not RM-recovered) of about one for each million in average, over a sequence 1 trillion long (about 18,000, 000 times smaller than allowed maximum). Representing the state of such a sequence would require 1M intervals, with about 12 bytes to code an interval of (long) integers (long starting number + length on 4bytes) about 12Mb is used for the sequence state.

For am RM Destination with tens of thousands of concurrent long-lasting sequences, it means that potentially terabytes of persistent space will be needed to store the state of these sequences. Also, the SequenceAcknowledgement element for such sequences may become extremely bulky (with such a rate loss above, could reach several Gb once the sequence gets big.)

Justification:

Space needs over time for sequences states is something unpredictable but manageable,

(somehow like cache management). If one wants to ensure the scalability of the RM mechanism, such dynamic policies as:

(1) deciding to arbitrarily end some existing sequence (e.g. LFU),

(2) dynamically adjust the maximum sequence length of new sequences at creation time,

should be supported (though their specification should remain out of scope).

For example, in many cases it is preferable to preventively limit the size of requested new sequences, and to decide that below a threshold of available memory, the maximum length of new sequences would get smaller. The RM specification is currently not open to such policies, mandating a fixed maximum to all sequences created regardless of resource status.

Target: core

Type: design

Proposal: (a) create another fault like "ResourceExhaustion" more explicit than "SequenceTerminated" fault, that allows the RM Source to understand the reason of

such an arbitrary termination by the RM Destination.

(b) In addition, if a smaller maximum has been dynamically decided by the RM Destination, communicate it to the RM Source via the CreateSequenceResponse.

ws-rx message