Subject: Re: Cisco SG16: Transaction ID uniqueness

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 16:00:04 -0500

Since there is no way for the requestor to know how long the responder will
take,
how long should it wait before sending a duplicate request, after it gets a
pend?

Whatever the answer is, that is the rate at which pends have to come.

If the timer is very long, then the timer to clear a missed final response
will be very long

Whatever the timer is, we may have to have repeated pends, and each of them
will be proceeded by a duplicate request in your proposal.

The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer is
short.

Brian

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

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

-----Original Message-----
From: Flemming Andreasen [ mailto:[email-masked]
<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
---------------------------------------

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

---

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

Hi Brian

Please look for FSA below (mail reader acting up here so sorry about the
formatting)

-- Flemming

"Rosen, Brian" wrote:
===============
Since there is no way for the requestor to know how long the responder
will take,
how long should it wait before sending a duplicate request, after it
gets a pend?

If the timer is very long, then the timer to clear a missed final
response will be very long

FSA: No. You make sure the final response is transmitted reliably by
requiring it to be acknowledged.

Whatever the timer is, we may have to have repeated pends, and each of
them
will be proceeded by a duplicate request in your proposal.

FSA: Correct

The scheme we have now is just like the one you propose, except that the
pends
come without prompt by the requestor, and the default value of the timer
is short.

FSA: No it's not. With my proposal, I can safely set the timer to say 30
seconds, and still detect a lost final response promptly. If I do
anything of the sort with your proposal, it will be a looooong time
before we recover.

Brian