Subject: Re: Cisco SG16: Transaction ID uniqueness

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 09:42:50 -0500

....snip......

> >v13 Status:     OPEN. No text changed.
> v14: SEMI-CLOSED. Draft text now specifies that "The transaction
> identifiers of incoming messages are compared to the transaction
> identifiers of the recent responses from the same entity",
> however "from"
> should be replaced with "to". Furthermore, "entity" should be
> clarified to
> specifically state that it is determined based on "mID".

I believe Chip is correct.

> >
> >Section:        D.1.1, second paragraph  Category:       Technical,
> >Editorial  Issue:          The draft text specifies that
> "The remaining
> >messages will be  compared to the list of current
> transactions. If a match
> >is found,  indicating a duplicate transaction, the entity
> does not execute
> >the  transaction, which is simply ignored". The above behaviour is
> >sub-optimal  and will lead to unnecessary retransmissions
> and adjustment
> >of  retransmission timers for subsequent transmissions. It is
> >furthermore  inconsistent with the description in Annex
> >D.1.4.  Proposal:       It is proposed that a "TransActionPending"
> >response is returned  instead.
> >
> >v13 Status:     OPEN. No text changed.
>
> v14: OPEN. No relevant text changed.
Same as the argument about immediate reply for a duplicate
request when a pend was lost; the timeout for a pend will
occur before a timeout from the duplicate request (or the final
response will be generated).  Sending another message immediately
just generates another message; it won't change behavior at the
requestor, since it must wait for it's timer to expire before sending
another duplicate and if it gets a pend, it will just reset it's
timer.  If the subsequent pend appears, the timer will be reset
short of its expiry.  If the pend is lost, the timer will expire
triggering another duplicate request, AS IT SHOULD.

Brian

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 11:00:42 -0500

Hi Brian

Some comments below

Regards

        Flemming Andreasen

> triggering another duplicate request, AS IT SHOULD.

Let's take a closer look:

MGC                MG
Request ->

        x-     Pending (now switches to a longer timer)
(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)