Subject: Re: Cisco SG16: Transaction ID uniqueness

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 15:21:27 -0500

Okay, I'll try

When you get a request, if it takes longer than "expected" time, you send
pends at a rate
around "expected" time.  If you get a pend, you increase your timer a bit so
that you
don't time out before the responder's pend timer times out.

If no messages are lost, the requestor gets a series of pends at about
"expected" time
intervals.  If one or more pends are lost, the requestors timer will expire
and it will send a
duplicate request.

In this case, the request will come some time after the pend which was lost
was
originally sent.  The requester doesn't expect a response for (at least)
"expected"
time, but the pend timer already running will expire before then.

So, in response to a duplicate, you could send a pend, but you will send one
sooner than the requestor's timer will expire even if you don't.  If that
gets lost too,
another duplicate will be sent, but I think that is okay.

So yes, the responder "bombards" the requestor with pends, at about
"expected"
rate.  There is a way to increase the timer, so you can slow down the rate
if you want to.  If you do, you would be expected to increase your timeout
time accordingly.  Frankly, I think the default is just about right, as
there is no
reason to expect delays longer than a few times the normal time.

How is that?

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Friday, February 04, 2000 3:05 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: Cisco SG16: Transaction ID uniqueness

Brian

Questions/comments below

-- Flemming

"Rosen, Brian" wrote:

MGC                MG
Request ->

        x-     Pending (now switches to a longer timer)

[br]Who has the longer timer?  The requestor, yes, the responder, no

Are you saying that the MG will keep bombarding the MGC with pending
messages until it can send a final one ? That seems rather wasteful in terms
of both bandwidth and processing.

(lost, so MGC sticks w. normal timer)

(timeout)
Request ->     (ignore since transaction is currently executing)
(timeout))
Request ->     (ignore since transaction is currently executing)
(timeout)
Request ->     (ignore since transaction is currently executing)
...
       <- Final
(finally)

[br]I think that you get a pend within the normal response.  If you lose the
pend, you generate one extra request duplicate, but the longer timer isn't
going to be twice normal time; you simply want to avoid the case of the pend
timer and the normal response timer being the same value and causing extra
messages when the requests/responses pass each other on the net.  If ALL the
pends are lost, you would see the above, but you would only get one extra if
only the first were lost.

I'm not sure I follow any longer. Can you explain the mechanism again,
perhaps with an example ?

Brian

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 15:47:16 -0500

Thanks

That made it clear.

While it certainly works, I think it's pretty wasteful in terms of
bandwidth and processing time - your solution has an inherent trade-off
between the two and expediency of message loss recovery. As long as your
assumption about short-lived transactions holds, that's not too bad,
however, even today, I can give you examples that break that assumption
(e.g. some forms of MF trunking).

An approach where only a single provisional response is transmitted
(assuming no losses) followed by a final reponse which itself is
acknowledged would avoid all of these problems. Consequently, I would
suggest that instead.

-- Flemming

"Rosen, Brian" wrote:

>  Okay, I'll tryWhen you get a request, if it takes longer than
> "expected" time, you send pends at a ratearound "expected" time.  If
> you get a pend, you increase your timer a bit so that youdon't time
> out before the responder's pend timer times out.If no messages are
> lost, the requestor gets a series of pends at about "expected"
> timeintervals.  If one or more pends are lost, the requestors timer
> will expire and it will send a duplicate request.In this case, the
> request will come some time after the pend which was lost
> wasoriginally sent.  The requester doesn't expect a response for (at
> least) "expected"time, but the pend timer already running will expire
> before then.So, in response to a duplicate, you could send a pend, but
> you will send onesooner than the requestor's timer will expire even if
> you don't.  If that gets lost too,another duplicate will be sent, but
> I think that is okay.So yes, the responder "bombards" the requestor
> with pends, at about "expected"rate.  There is a way to increase the
> timer, so you can slow down the rateif you want to.  If you do, you
> would be expected to increase your timeouttime accordingly.  Frankly,
> I think the default is just about right, as there is noreason to
> expect delays longer than a few times the normal time.How is
> that?Brian
>
>      Are you saying that the MG will keep bombarding the MGC with
>      pending messages until it can send a final one ? That seems
>      rather wasteful in terms of both bandwidth and processing.
>
>
>     >
>     >
>     >
>     >      [br]I think that you get a pend within the
>     >      normal response.  If you lose the pend, you
>     >      generate one extra request duplicate, but the
>     >      longer timer isn't going to be twice normal
>     >      time; you simply want to avoid the case of the
>     >      pend timer and the normal response timer being
>     >      the same value and causing extra messages when
>     >      the requests/responses pass each other on the
>     >      net.  If ALL the pends are lost, you would see
>     >      the above, but you would only get one extra if
>      I'm not sure I follow any longer. Can you explain the
>      mechanism again, perhaps with an example ?
>
>     >
>     >
>     >      >
>     >      >
>     >      > Brian
>     >
>      --