Subject: Re: Cisco SG16: Transaction ID uniqueness

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 17:03:25 -0500

The necessary changes appear to have been made in v14.

> -----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
>
> 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: Chip Sharp <[email-masked]>
Date: Fri, 4 Feb 2000 00:02:03 -0500

At 05:03 PM 2/2/00 -0500, Tom-PT Taylor wrote:

>The necessary changes appear to have been made in v14.
Not quite - see below.
>
>-----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
>
>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.
>
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".
>
>
>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.
>

v14: OPEN. No relevant 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.
>
v14: CLOSED. Text updated.
>
>
>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.
>
>consistent with  Section 8.1.1, i.e. that the combination of transaction
>identifier and mId  identifies a given transaction.
>
v14: CLOSED. Text updated.
>    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.
>

v14: CLOSED. Text updated.
>
>
>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.
>
v14: CLOSED. Text removed (now Section D.1.5)

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 07:35:30 -0500

Resend

> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Friday, February 04, 2000 2:18 AM
> To:   'Chip Sharp'; [email-masked]
> Subject:      RE: Cisco SG16: Transaction ID uniqueness
>
> Proposed changes added to the errata document.
>
> Sent: Friday, February 04, 2000 12:02 AM
> Subject:      Re: Cisco SG16: Transaction ID uniqueness
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 15:38:30 -0500

We've just gone through a pile of this with SIGTRAN.  Even if we aren't
using their transport (yet), it would be nice if we could build on their
congestion avoidance algorithms.  Otherwise we'll be tinkering for months.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 3:21 PM
> 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
>
>       From: Flemming Andreasen [mailto:[email-masked]]
>       Sent: Friday, February 04, 2000 3:05 PM
>       To: Rosen, Brian
>       Cc: [email-masked]
>       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: Tom-PT Taylor <[email-masked]>
Date: Fri, 4 Feb 2000 15:49:25 -0500

Actually, I wasn't concentrating -- what you're dealing with here isn't
quite the same as congestion avoidance.  In a way it's more complicated,
because congestion is potentially part of the picture.  Anyway, I won't
insist we have to go to SCTP unless this issue drags on and on.

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Friday, February 04, 2000 3:44 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
> So are you advocating copying and modifying a boatload of text from SCTP
> now?
>
> Brian
>
>       From: Tom-PT Taylor [mailto:[email-masked]]
>       Sent: Friday, February 04, 2000 3:39 PM
>       To: [email-masked]
>       We've just gone through a pile of this with SIGTRAN.  Even if we
> aren't using their transport (yet), it would be nice if we could build on
> their congestion avoidance algorithms.  Otherwise we'll be tinkering for
> months.
>
>       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
>       If no messages are lost, the requestor gets a series of pends at
> about "expected" time
>       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"
>       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,
>       time accordingly.  Frankly, I think the default is just about right,
> as there is no
>               From: Flemming Andreasen [
> <mailto:[email-masked]>]
>                                       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.
>
>
>
>
>
>                               [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
>
>                       --

---

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

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Friday, February 04, 2000 3:21 PM
To:     [email-masked]
Subject:        Re: Cisco SG16: Transaction ID uniqueness

        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

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.

        (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.

        Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 17:51:45 -0500

I made a mistake.  Dialtone is indeed TO, and the
correct thing happens (first digit event stops dialtone).

I don't seriously propose changing the current syntax,
although we might want to adjust the wording of signals
to highlight that most events DON'T stop signals, only
TO without KeepActive.

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

Fair enough. Given that, I would prefer changing Annex D.
-- Flemming
"Rosen, Brian" wrote:
 Acks are a function of transport.  The ACK syntax we have is UDP only.You
can't, in general, require an ACK, immediate or not.We could, theoretically,
change Annex D to do what you ask, but we couldn'tchange the main body of
the text.  Given that, what would you want to do?I'd rather leave it as it
is right now, and get some experience.Brian
-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Friday, February 04, 2000 4:39 PM
To: [email-masked]
Subject: Re: Cisco SG16: Transaction ID uniqueness

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?
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

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
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------