time management: the options

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: time management: the options

Here is a summary of the two major options I believe we face about dealing with timing, as outlined in previous mails,
and my analysis of their advantages / disadvantages.
After consideration, I personally favor Proposal #1 (the one we started on at f-2-f).

Tomorrow I will map this time management proposal to our list of current issues,
and propose corresponding resolution/impact to several of them.
The schema so far is same as last proposed in f-2-f.

Jacques

Proposal #1: (use time parameters)
-----------
Uses ExpiryTime, GroupExpiryTime, MaxGroupIdleTime, here carried in the protocol
(messages), as discussed last f-2-f.
The group termination follows rules based on these values, as we outlined them
in f-2-f, and of which I propose/summarize a complete version in draft sent out Nov 2.

Advantage:
- group duration, scope of duplicate check, is clearly controlled
by these parameters. Semantics is clear to users.
- control of storage space is better (much less chance to overflow available space)
- synchronization between sender and receiver via protocol (same understanding
on both sides, of persistence conditions).

Drawbacks:
- possible abuse by users (the RMP may have to "cap" these values, based
on some configuration).
- implementors must implement these rules in order to conform to spec (more complex).

Proposal #2: (timeless)
------------
Does NOT specify ExpiryTime, GroupExpiryTime, MaxGroupIdleTime.
Instead, groups and message IDs are kept open and persisting until some garbage
collection takes place, controlled by config for each implementation.

Advantage:
- no "termination" management is required to conform to specification. Simpler spec,
Easier to implement.

Drawbacks:
- the contract about the scope of dup elimination, of group duration, is unclear
as controlled by storage availability, possibly differently by each impleemntation.
- synchronization of termination and removal of states between Sender and Receiver unclear.
- more chance to overflow available storage, watermark parameters for space limits
will be reached more often, making terminations of persisted groups and message IDs
unpredictable.