MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] CSMA Back-Off Algorithm
Patrick,
Thanks for your comments. The added variables would become part of the
higher level contract (e.g. CPA), so it would NOT ever be something
arbitrarily applied by a single party.
Best Regards,
Matt
On 6/19/04 10:55 AM, "Patrick Yee" <kcyee@cecid.hku.hk> wrote:
> Matt,
>
> Thanks for your prompt explanation. While the backoff algorithm helps in
> reducing the system loading, does it fail to address the service
> contract? If we view the statement "try to retransmit every 30 seconds"
> as a partner agreement from higher level (e.g. CPA in ebXML suite), it
> seems to me that the ebMS layer should implement that. What I try to
> point out is that, implementation of a more advanced algorithm needs
> more configuration to the ebMS handler, and sometimes this will impact
> the coupling of higher level specificatons.
>
> Just my $0.02.
>
> Regards, -Patrick
>
>
> Matthew MacKenzie wrote:
>
>> Patrick,
>>
>> At the ebMS face to face meeting last week in Ottawa, improving the retry
>> mechanism popped up as an issue we would like to address.
>>
>> The Back-Off algorithm in CSMA seems like suitable prior art to consider in
>> this issue. Consider the following:
>>
>> "A reliable message exchange that must complete within 2 days. If the
>> remote party is unavailable, try to retransmit every 30 seconds."
>>
>> Expiration (e) = P2D
>> Retry Interval (ri) = P30S
>>
>> If the remote host experiences an extended period unavailability, valuable
>> CPU and network resources are wasted on the sending side for 2 days just to
>> figure this out. If we apply a back-off algorithm, we can at least reduce
>> the time allotted to transmitting or attempting to transmit a message to a
>> host that is not available.
>>
>> So, with a modified back-off algorthim, we would have:
>>
>> Expiration (e) = P2D
>> Retry Interval (ri) = P30S
>> Back-Off Multiplier (bom) = 1.5
>> Multiplications before reset (mbr) = 10
>>
>> Given the above, transmission attempts would look like:
>>
>>
>> ri+0s: transmit
>> ri+30s since last transmit
>> ri+45s since last transmit
>> ri+67.5s since last transmit
>> ri+101.25s since last transmit
>> ri+151.88s since last transmit
>> ri+227.81s since last transmit
>> ri+341.7s since last transmit
>> ri+512.6s since last transmit
>> ri+768.9s since last transmit
>> (reset occurs, ri=0)
>>
>> This cycle would continue until the point of expiration. I've added the
>> "reset" so that messages with shorter expiration periods have a reasonable
>> chance of being transmitted. If we ran without the reset in a situation
>> where the expiration period ended in 2 days, it really wouldn't take long
>> before ri reached a point beyond 2 days (172800s).
>>
>> Regards, Matt
>>
>>
>>
>>
>> On 6/19/04 10:11 AM, "Patrick Yee" <kcyee@cecid.hku.hk> wrote:
>>
>>
>>
>>> Hi,
>>> This is a very interesting proposal. May we know how the CSMA algorithm
>>> helps to improve the retry mechaism?
>>> Regards, -Patrick
>>>
>>>
>>> Matthew MacKenzie wrote:
>>>
>>>
>>>
>>>> On the topic of improving our retry algorithm, I think a variant of the
>>>> Back-Off algorithm used in Carrier Sense Multiple Access may be suitable.
>>>> Me may want to specify a "reset interval", so that the delay does not built
>>>> up to such a high number that the message is never transmitted after an
>>>> extended loss of connectivity.
>>>>
>>>>
>>>>
>>>> http://www2.rad.com/networks/2001/ethernet/backof.htm
>>>>
>>>> "Each sender will delay after a collision before attempting to retransmit.
>>>> If they will delay for the same time, another collision will occur. That¹s
>>>> why each sender chooses a random delay between 0 and d (d is some standard
>>>> delay value). If, nevertheless, another collision occurs, each computer
>>>> doubles the range from which the delay is chosen, that means, the random
>>>> delay will now be between 0 and 2d. If another collision occurs the range
>>>> will be between 0 and 4d and so onŠ After each collision the range of the
>>>> random delay increases exponentially, therefore the probability of
>>>> collision
>>>> rapidly decreases and after few iterations becomes negligible."
>>>> ___________________________
>>>> Matthew MacKenzie
>>>> Senior Architect
>>>> IDBU Server Solutions
>>>> Adobe Systems Canada Inc.
>>>> http://www.adobe.com/products/server/
>>>> mattm@adobe.com
>>>> +1 (506) 871.5409
>>>>
>>>>
>>>>
>>>> To unsubscribe from this mailing list (and be removed from the roster of
>>>> the
>>>> OASIS TC), go to
>>>> http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgr
>>>> ou
>>>> p.php.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> ___________________________
>> Matthew MacKenzie
>> Senior Architect
>> IDBU Server Solutions
>> Adobe Systems Canada Inc.
>> http://www.adobe.com/products/server/
>> mattm@adobe.com
>> +1 (506) 871.5409
>>
>>
>>
>>
>>
>
___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
mattm@adobe.com
+1 (506) 871.5409
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]