[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)
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]