[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: T2 Clarify TimeToLive
FYI - I think this one is already on our list.
As I pointed out earlier in this thread, the stated formula is not correct
because it doesn't take into account the MSH's timeout that triggers the
retry. That timeout is currently undefined. What is also undefined is
when the RetryInterval begins - is it when the message is sent or when the
MSH times out?
This really has to be a joint CPPA-MSG item.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 09/13/2001
09:05 AM ---------------------------
David Fischer <david@drummondgroup.com> on 09/12/2001 09:28:38 PM
To: "Burdett, David" <david.burdett@commerceone.com>, "'Christopher
Ferris'" <chris.ferris@sun.com>
cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Subject: RE: T2 Clarify TimeToLive
I agree with Arvola, let's let CPPA own this one.
David Fischer
Drummond Group.
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Wednesday, September 12, 2001 5:11 PM
To: 'Christopher Ferris'
Cc: 'David Fischer'; ebXML Msg
Subject: RE: T2 Clarify TimeToLive
It should be, I agree, but what do you do if it is not. Should it be
reported as a "warning" error?
David
-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Wednesday, September 12, 2001 2:51 PM
To: Burdett, David
Cc: 'David Fischer'; ebXML Msg
Subject: Re: T2 Clarify TimeToLive
Actually, you also need to take into consideration
that TTL needs to be less than the persistDuration, no?
Cheers,
Chris
"Burdett, David" wrote:
>
> Almost. I think that really it should be ...
>
> TimeToLive > Sum Of [SendTime + (Retries * RetryInterval)] over
> all hops + some percentage
>
> As you cannot always know how many hops there will be nor how fast each
hop
> would be, you really should make TimeToLive a lot more than the figure
> above. In practice, I think that feedback from actual use is likely to be
> the most effective way to work out the values to use.
>
> David
>
> -----Original Message-----
> From: David Fischer [mailto:david@drummondgroup.com]
> Sent: Wednesday, September 12, 2001 8:03 AM
> To: ebXML Msg
> Subject: RE: T2 Clarify TimeToLive
>
> >> I think adding this to the spec as a non-normative note is a good
idea.
>
> Very Good. I mostly realized the potential for problems when I realized
> this
> could cause a recalculation of the signature. I guess the answer is:
>
> TimeToLive > SendTime + (Retries * RetryInterval)
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Tuesday, September 11, 2001 11:50 PM
> To: 'Arvola Chan'; David Fischer; ebXML Msg
> Subject: RE: T2 Clarify TimeToLive
>
> Currently TimeToLive is defined in section 8.4.6.4 as ...
>
> The TimeToLive element indicates the time by which a message should be
> delivered to and processed by the To Party.
>
> ... and in section 10.2.3 as ...
>
> The TimeToLive value indicates the time by which a message should be
> delivered to and processed by the To Party.
>
> What I think you are suggesting is that we provide guidance on how it
should
> be set. There are two factors which can affect this:
> 1. Setting it to a value long enough so that it is longer that the time
> required to do all the retries on all the hops between the From and To
> Parties. By definition this is not precisely computable.
> 2. Setting it to a value that makes sense in a business context, e.g. if
> this PO gets there in a day then it is fine.
>
> I think adding this to the spec as a non-normative note is a good idea.
>
> David
>
> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Tuesday, September 11, 2001 5:12 PM
> To: David Fischer; ebXML Msg
> Subject: Re: T2 Clarify TimeToLive
>
> David:
>
> I agree with you that we need to clarify in the spec how TimeToLive
> should be set for a given message. For reliably delivered messages,
> I don't think we want to reset the the TimeToLive on every retry. It just
> incurs unnecessary signature recomputation overhead. I would suggest
setting
> TimeToLive to current time (for the initial attempt) + (retry + 1) *
> retryInterval. This must also be less than the receiver MSH's persist
> duration.
>
> For messages delivered by BestEffort, the TimeToLive can either be
> omitted, or perhaps set to the current time plus the
> RequestingBusinessActivity's or RespondingBusinessActivity's
> timeToReceiveAcknowledgment.
>
> Cheers,
> -Arvola
>
> -----Original Message-----
> From: David Fischer <david@drummondgroup.com>
> To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
> Date: Tuesday, September 11, 2001 4:52 PM
> Subject: T2 Clarify TimeToLive
>
> I don't know if this is a problem or not. TimeToLive is a time, not an
> interval, and should probably be set to current time plus 1/2
RetryInterval
> (half of the round trip from sender to receiver back to sender). Won't
this
> have to be recalculated each retry? Won't this invalidate the signature?
>
> Maybe I'm getting the correct value of TimeToLive wrong? What in the
world
> should this be? Maybe this is more along the lines of "This PO is valid
for
> 30
> days" so this value should be set to current time plus 30 days? In any
> case, we
> probably need to clarify the spec.
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC