Re: [ws-rx] NEW ISSUE: rewording of Proposed-01 (twin sister of i019)

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Jacques,

Nit:
What your are suggesting is -- to provide a mechanism for the RMS to get 
an accurate read of which messages have been received by the RMD in the 
fault-case (non-normal termination of the sequence -- for whatever 
reason the sender wants to terminate the sequence and cannot wait for 
all the ACKs to be received) and a promise from the RMD not to delivery 
  laggard messages that may arrive later. As you say this is a 'twin 
sister of i019'. The difference between this and i019 is -- where the 
fault originates. In the case of i019 the fault is initiated by the RMD 
whereas in this case it is initiated by the RMS. I would like to suggest 
that i019 issue be named:
"Non-normal Sequence termination on Fault Originating at RMD" instead of 
"Sequence termination on Fault" and this issue be titled "Non-normal 
Sequence termination on Fault Originating at RMS." This is to avoid the 
sort of misunderstanding of the issue (as on today's call), where this 
issue was thought to be about normal termination (with the sending of 
TerminateSeqence message).

Makes sense?

-Anish
--

Jacques Durand wrote:
> Rewording of Proposed-01:
> 
>  
> 
>  
> 
> Title: Accuracy of final acknowledgement reflecting termination state of 
> a sequence.
> 
>  
> 
> Description: When a Source decides to stop using a sequence, there is no 
> way the RMS can get
> 
> a sequence ack that it knows will accurately reflect the final state of 
> the sequence, i.e. the state the sequence will have at actual 
> termination time. No matter how long an RMS waits after its last sending 
> and before requesting its last Ack, some past message that was 
> previously sent and never acknowledged (for which RM Source had stop any 
> resending effort) could be received late by RMD (e.g. after being stuck 
> in a router), i.e. after the sending of the last SequenceAcknowledgement 
> and before the sequence is actually terminated so that the RMD can 
> reclaim resources. This is the twin sister of issue i019 which deals 
> with a similar problem but in case of sequence fault (which gives no 
> chance to RMS to get this final seq ack.)
> 
>  
> 
> Justification: An RMS (or SA) may decide to stop using a sequence even 
> though some messages were not received (not acked). But in all cases, it 
> is important that the RMS gets a final accurate account of which 
> messages have been received and which have not for this sequence. The 
> RMS may have to raise an error for those not received. Also if the SA 
> decides to take remedial action for these (e.g. some resending on its 
> own) it must be given some means to avoid treating messages that it did 
> not know were already received in a previous sequence (e.g. avoid 
> resending them later in a new sequence as they would become undetectable 
> duplicates.)
> 
>  
> 
> Target: core
> 
> Type: design
> 
>  
> 
> Proposal: TBD. Outline of a solution:
> 
> (a) give an RMS a way to trigger a SeqAck that will be associated with 
> the "closing" of the sequence i.e. no more message will be accepted by 
> the RMD after this Ack is generated.
> 
> (b) give an RMS a way to reiterate this trigger in case it is lost, so 
> that it can get this last SeqAck.
>