RE: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL)

[Scott Werden <scottw@wrq.com>]

Comments: <scott></scott> inline...

> -----Original Message-----
> From: Alan Weissberger [mailto:ajwdct@technologist.com] 
> Sent: Wednesday, July 09, 2003 2:31 PM
> To: Jun Tatemura; Paolo.Romano@dis.uniroma1.it; 
> wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time To 
> Live (TTL)
> 
> 
> Paolo
> 
> Clarification on why we need a Message Expiration time and an 
> upper bound (=absolute maximum) Message Duration time:
> 
> 1.  We should redefine ttl as the latest (actual) time, that 
> the message can be delivered to the WS-RM client.  [Let's 
> rename it "message expiration time," instead of TTL].  This 
> time includes message delivery/ transit time + retransmission 
> time (if necessary)+ message persist (=store and hold) time 
> at the WS-RM receive entity (if necessary).

<scott>
I agree with Alan that TTL does not accurately reflect what the parameter
represents. MET does seem better.
</scott>

> 
> The WS-RM receive entity may have to be persist (=store) the 
> received message up to the message expiration time if the 
> WS-RM client is busy/ unavailable/used local (=inter-layer) 
> flow control.  
> 
> 2.  I proposed that "Maximum duration" should be a 
> configuration/ subscription parameter that is urgently needed 
> so we have an upper bound on Message Expiration time.  This 
> would prevent very long hold/persist and/or message delivery times. 
>

<scott>
While "max duration" does seem like a very reasonable piece of info for the
sender to have, I think it falls in the bucket of other QOS parameters that
we have discussed and is something negotiated out-of-band and the spec
should probably not specify the semantics of out-of-band parameters. 

On the other hand, I think the spec should address the semantics of WSRM
parameters that the receiver cannot honor, including an MET that the
receiver "knows" it can never support. 
</scott>
 
> Message Expiration time= current time (at the sender) + 
> maximum duration of this message (which is less than the 
> absolute maximum duration time parameter set at subscription/ 
> configuration time).  
> 
> 3.  More importantly, if the WS-RM receive entity receives a 
> message that has expired, it should be discarded.

<scott>
Agreed - receiving an expired messages should ALWAYS be discarded, however,
I do not think this should be silent but must raise a fault.

As someone pointed out, we need to define the message flow for faults. The
following logic I think will work for any binding:
IF transport is req/reply AND the SOAP MEP is req/reply THEN
	add WSRM fault headers to SOAP reply
ELSE
	create new one-way SOAP message (with empty body) and send it to the
"replyTo" address.
ENDIF

BTW, I think the above is the same logic for a WSRM ACK.

</scott>

> 
> alan
> ----- Original Message -----
> From: "Jun Tatemura" <tatemura@ccrl.sj.nec.com>
> Date: Wed, 9 Jul 2003 10:47:13 -0700
> To: <Paolo.Romano@dis.uniroma1.it>, <wsrm@lists.oasis-open.org>
> Subject: Re: [wsrm] Rel 44:  Duplicate Elimination and Time 
> To Live (TTL) 
> 
> > Paolo,
> > Let me state my understanding on what Alan said.
> > 
> > > A simple question: why do we distinguish between maximum 
> duration (i.e. maximum
> > > time in the persistent storage) and ttl (i.e. maximum 
> time before the message is
> > > delivered to the final application, please correct me if 
> I am wrong)?
> > >  Why we do not just use one of them? I mean, if we define 
> ttl as the maximum
> > > time before the message is delivered, then it will have 
> to be persisted up to
> > > that time. What are the advantages of having both of 
> them? Why should a message
> > > be persisted longer than ttl? The receiving rm-processor 
> should anyway raise a
> > > fault.
> > 
> > Maximum duration means that the receiver can not (will not) 
> persist a message any longer
> > than it due to some limitation in its implementation. It 
> indicates the upper limit of TTLs based on
> > the receiver's capability. For example, the receiver may 
> not want to preserve a message for 100 year.
> > Such requests should be rejected (or ignored). The sender 
> and the receiver should have agreement on
> > the maximum duration as one of the features of the 
> receiver's service level.
> > 
> > TTL (or Expiration Time), on the other hand, is specified 
> for each message based on the
> > sender's business needs.
> > 
> > Alan's 2(a) error means that, when the expiration time of a 
> message is larger than a threshold
> > (i.e., max duration + current time),  the receiver can say 
> "hey, I can not hold your message that long."
> > (Alternative way is that the receiver silently ignores the 
> TTL requested and sets a (default) TTL based
> > on its maximum duration)
> > 
> > So, a message will not be persisted longer than TTL in any case.
> > 
> > Regards,
> > Jun
> > 
> > > > Alan Weissberger <ajwdct@technologist.com> ha detto:
> > > >
> > > > > All
> > > > >
> > > > > The Issues List indicates that Rel 44 Duplicate 
> Elimination and Time to Live
> > > > (TTL)is CLOSED, but on last week's conference call I 
> believe we decided to pursue
> > > as
> > > > follows:
> > > > >
> > > > > New Spec issue: What should receiver do if it 
> receives an Expired message?
> > > > > Related issue: better define semantics of TTL
> > > > >
> > > >
> > > 
> --------------------------------------------------------------
> ----------------------
> > > > >
> > > > > 1.  Time To Live
> > > > >
> > > > > I always wondered how the receiver knows that the 
> message it just received has TTL
> > > > expired?
> > > > >
> > > > > I was told by a colleague that TTL is not the 
> duration of the message (as one
> > > > would expect from its meaning in networking), but it's 
> the actual time that the
> > > > message expires.  If that is the case than it should be 
> renamed "message expiration
> > > > time."  (It's like the "Expires" entity of an HTTP header)
> > > > >
> > > > > We make the following assumptions on the sender and 
> receiver that can handle TTL
> > > > (or Expiration Time):
> > > > >
> > > > > (a) They have agreed on the Maximum Duration for 
> expiration (the receiver does not
> > > > want to keep messages forever).  This could be done as 
> part of a subscription/SLA
> > > or
> > > > as a capability exchange/configuration message sequence 
> at start-up time (i.e.
> > > prior
> > > > to sending WS data messages).
> > > > >
> > > > > Suggest we include this Maximum Duration value into 
> the list of configurable
> > > > parameters.
> > > > >
> > > > > (b) Their clocks are properly synchronized to avoid 
> pre-mature or late expiry of
> > > > the message (i.e. the time difference between sender 
> and receiver clocke should be
> > > > less than some agreed upon threshold)
> > > > >
> > > >
> > > 
> --------------------------------------------------------------
> ----------------------
> > > > >
> > > > > 2.  What should receiver do if it receives an expired message
> > > > >
> > > > > (a) First, if the receiver detects the Message 
> Expiration time (now known as TTL)
> > > > is greater than the agreed upon Maximum Duration, then 
> the message should be
> > > > discarded and a Fault Message generated with Cause 
> Code= Coding error in Message
> > > > Expiration field.  This is detected by the receiver 
> when Message Expiration (of
> > > > received message) - Current Time > Max duration.
> > > > >
> > > > > (b) Second, if the receiver detects Message 
> Expiration time is later than current
> > > > time, then message should be discarded and Fault 
> Message generated with Cause Code=
> > > > Message arrived after Expiration time.
> > > > >
> > > > > Unresolved Issue:  If the message exchange pattern is 
>  1-way only, then should we
> > > > still allow fault messages to be sent in opposite 
> direction?  In other words,
> > > permit
> > > > 1 way SOAP message transfer, but require 2-way control/ 
> error messaging at WS-RM
> > > > layer (above SOAP).
> > > > >
> > > > >
> > > > > Alan Weissberger
> > > > > NEC Labs America
> > > > > 1 408 863 6042 voice
> > > > > 1 408 863 6099 fax
> 
> 
> 
> 
> 
> You may leave a Technical Committee at any time by visiting 
http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
p