Subject: Cisco SG16: Transaction ID uniqueness

From: Chip Sharp <[email-masked]>
Date: Tue, 25 Jan 2000 20:06:39 -0500

Section:        D.1.1, second paragraph
Category:       Technical, Editorial
Issue:          The draft text specifies that “The transaction identifiers of 
incoming messages are compared to the transaction identifiers of the recent 
responses”. This is inconsistent with Section 8.1.1 where transaction 
identifiers are defined to only be unique within the scope of a given 
sender. Transaction identifiers should indeed be unique within the scope of 
a given sender to avoid having to synchronize transaction identifiers 
between MGC’s, e.g. when handoff or failover is performed.
Proposal:       It is proposed that the text is modified to be consistent with 
Section 8.1.1.

v13 Status:     OPEN. No text changed.

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.

Section:        D.1.1, last paragraph.
Category:       Technical, Editorial
Issue:          The draft text specifies that “For transactions that are 
acknowledged through this parameter, the MG shall keep a copy of the 
transaction-id for LONG_TIMER seconds after the response is issued, in 
order to detect and ignore duplicate copies of the transaction response”. 
The sentence is incorrect as the purpose of the keeping the transaction-id 
(but not the response) at the MG is to recognize duplicate transaction 
requests which can then be ignored with it is known that the requestor 
already received the response.
Proposal:       It is recommended that “transaction response” is changed to 
“transaction request” in the above sentence. Furthermore, it is recommended 
the “the MG” is changed to “the MG (or MGC)” as the behaviour applies to both.

v13 Status:     OPEN. No text changed.

Section:        D.1.2, first paragraph, last line
Category:       Technical, Editorial
Issue:          The draft text specifies that “MGs can simply detect duplicate 
transactions by looking at the transaction identifier only”. This is 
inconsistent with the “sender uniqueness only” requirement on transaction 
identifiers in Section 8.1.1, which implied that MGs have to look at the 
combination of “mId” and transaction identifier to identify a duplicate 
transaction.

Proposal:       It is recommended that the text is modified to be consistent with 
Section 8.1.1, i.e. that the combination of transaction identifier and mId 
identifies a given transaction.

v13 Status:     OPEN. No text changed.

Section:        D.1.2, fourth paragraph
Category:       Technical
Issue:          The draft text specifies that “The entity shall retain the union of 
the “confirmed transaction-id ranges” received in recent messages”. This is 
inaccurate. More specifically, a given “confirmed transaction-id range” is 
valid for LONG-TIMER seconds.
Proposal:       It is proposed that the text is modified to reflect the above.

v13 Status:     OPEN. No text changed.

Section:        D.1.4, fourth paragraph
Category:       Technical
Issue:          The draft text specifies that “The transaction identifiers of 
incoming transactions are compared…”. The paragraph duplicates Section 
D.1.1 and contains the same problem of ignoring the “sender uniqueness 
only” requirement on transaction identifiers as well as not issuing a 
provisional response when a duplicate request for an in-progress transaction.
Proposal:       It is proposed that the paragraph is either removed or the text 
modified to reflect the “sender uniqueness requirement” and sending of a 
provisional response.

v13 Status:     OPEN. No text changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 27 Jan 2000 15:52:20 -0600

This looks reasonable.

> -----Original Message-----
> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Tuesday, January 25, 2000 8:07 PM
> To:   [email-masked]
> Subject:      Cisco SG16: Transaction ID uniqueness
>
> Issue:          The draft text specifies that "The transaction identifiers
> of
> responses". This is inconsistent with Section 8.1.1 where transaction
> between MGC's, e.g. when handoff or failover is performed.
        [[TomT]]  other issues snipped
> Issue:          The draft text specifies that "MGs can simply detect
> duplicate
> transactions by looking at the transaction identifier only". This is
> inconsistent with the "sender uniqueness only" requirement on transaction
> combination of "mId" and transaction identifier to identify a duplicate
> transaction.
>
        [[TomT]]  other issues snipped
> Issue:          The draft text specifies that "The transaction identifiers
> of
> incoming transactions are compared...". The paragraph duplicates Section
> D.1.1 and contains the same problem of ignoring the "sender uniqueness
> only" requirement on transaction identifiers as well as not issuing a
> modified to reflect the "sender uniqueness requirement" and sending of a
> provisional response.
>