[no subject]

A final acknowledgement status could be sent back that reflects the =
exact state at termination time. That could be done by sending (or by =
making available for polling even after the sequence is terminated) a =
last SequenceAcknowledgement element, at the time the RM Destination =
terminates the sequence (either at reception of TerminateSequence, or =
due to timeout). Such a SequenceAcknowledgement element should have a =
"last" marker.=20

proposed-02=20

better support in handling space-greedy sequences=20

core - design - unassigned

=20

Description=20

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.)=20

Justification=20

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:=20

*         (1) deciding to arbitrarily end some existing sequence (e.g. =
LFU)=20

*         (2) dynamically adjust the maximum sequence length of new =
sequences at creation time=20

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.=20

Origin=20

Jacques Durand =
<http://lists.oasis-open.org/archives/ws-rx/200508/msg00061.html> =20

Owner=20

Jacques Durand =
<file:///\\cpzaw-pro-05\mydocs4\mgoodner\Visual%20Studio%202005\Projects\=
WS-RM%20Issues\IssueList\JDurand@us.fujitsu.com> =20

Proposal 12005-08-09=20