OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

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. 

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.

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






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]