Subject: [AAA-WG]: issue 372 proposed text

From: <[email-masked]>
Date: Wed, 16 Oct 2002 18:19:37 +0300

Hi Bernard (and others),

I would propose the following text for your consideration.

Br
Marco

I guess we need more clear explanation when D flag should be set than the one
currently proposed in issue 372, then the following text could be used instead:

 (possible) D(uplicate)
                     - This flag is defined only for Accounting Requests
                       sent by a Diameter client or agents.
                       If set, the message is a possible duplicate and
                       a recipient node MAY later check if it really is a 
			     duplicate. 
			     If sending a message for first time, this flag MUST be
                       cleared.
                       It can be used only in cases where no answer has been 
			     got from the Server for a message and the message is
                       sent again (e.g. due to a failover to an
                       alternate agent, due to a recovered primary peer
                       node or due to a client re-sendind a stored record).
			     This flag MUST NOT be set if an error answer message
                       (about e.g. a protocol error) has been got for an earlier 
                       similar message. It can be used only in cases where no 
                       answer has been got from the Server for a message 
                       and the message is sent again (e.g. due to a failover to an
                       alternate agent, due to a recovered primary peer
                       node or due to a client re-sendind a stored record).
                       This flag MUST NOT be set in answer messages.

And here is the proposal for AnnexC. A better example how the server may use
the D-flag is given as well as worning proposed by Jari, the proposal is to 
change the last two paragraph with the following text.

   "The following is an example of how the D-flag may be used by the server to 
   detect duplicate records. Implementers are advised, however, that configuration 
   errors in the network or software errors cannot be detected solely by using 
   the D-flag.
   
   Diameter server MAY check the D-flag of the received message to determine
   if the record is a possible duplicate. With the D-flag usage, the checking 
   is based on tracking Session-ID and possibly Accounting-Record-Number AVPs.
   That tracking may be done for a configurable time window to future and to 
   past for the corresponding AVP pairs, per a certain accounting record arriving 
   to a recipient Diameter node. Only when a D-flag marked (i.e. D-flag set) 
   accounting record is countered, its Session-ID and possibly 
   Accounting-Record-Number AVP pair is buffered for a possible future check,
   but no check is needed immediately. The checking is done, Session-Id and
   possibly Accounting-Record-Number AVPs of the D-flag marked record against 
   the other Session-ID and possibly Accounting-Record-Number AVP pairs 
   of the time windows. If the duplicate record is not found in the backward and 
   forward (e.g. 2 * TIME_WAIT) time windows, then the D-flag mark is not removed
   from the accounting record when sending it further towards the end system.
   The network's accounting end system can be understood and implemented as 
   a central logical entity (no matter if it would physically consist of several 
   servers). It could then be left to the end system to compare the possible
   still existing  D-flag  marked records against others in a configurable 
   backward and forward (e.g. 2* TIME_WAIT) time windows.
   Since backward and forward time windows are used to check if the D-fag marked
   record is really a duplicate, out of order accounting records is not an issue."

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Oct 2002 10:40:14 +0300

>  (possible) D(uplicate)

T, potentially retransmitted message

>                      - This flag is defined only for Accounting Requests

all requests

>                        If set, the message is a possible duplicate and

s/message/request/g

and

This flag is used as an informative indication of an application
layer retransmission event, e.g. due to failover to an alternate
server, or due to resending accounting records from non-volatile
memory after a reboot of the client.

If a Diameter client or agent knows that it is sending this
request or accounting record contained in the request for the first time,
it MAY reset this flag.

If request is either known to be a retransmission or the Diameter
client or agent is unable to assure that it is the first such request,
it MUST set this flag.

Diameter agents that receive a request with the T flag set, MUST
keep the T flag set in the forwarded request.

Diameter servers MAY use the T flag as an aid when processing requests
and detecting duplicate messages. However, servers that do this MUST
ensure that duplicates are found even when the the first transmitted
request arrives at the server after the retransmitted request.

>                        node or due to a client re-sendind a stored record).

Delete all of the above.

>                        This flag MUST NOT be set in answer messages.

Ok.

>    errors in the network or software errors cannot be detected solely by using 

Ok.

>    Diameter server MAY check the D-flag of the received message to determine

Let's not use keywrods in the appendix. These are non-normative anyway.

>    record is really a duplicate, out of order accounting records is not an issue."

I haven't checked this.

Jari