Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set)

From: <[email-masked]>
Date: Thu, 17 Oct 2002 12:05:16 +0300

Hi,

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

I think this should be MUST since if the message is sent for the
first time the T flag is not to be set.

Also the text in Appendix C should be more generic and shoudn't
refer to Session-Id and Accounting_Record_Number pairs as indicated
by Ohba.

I have collected the full set of changes so as to simplify the
checking to all of you.

Best Regards
Marco

3 Diameter Header

Change the header

  0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E r r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Application-ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop-by-Hop Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      End-to-End Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

To

  0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Ver      |                 Message Length                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E T r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Application-ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Hop-by-Hop Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      End-to-End Identifier                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  AVPs ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-

Add the "T" flag description between "E" flag description and "r" flag 
description.

	   R(equest)   - If set, the message is a request. If cleared, the
                       message is an answer.
         P(roxiable) - If set, the message MAY be proxied, relayed or
                       redirected. If cleared, the message MUST be
                       locally processed.
         E(rror)     - If set, the message contains a protocol error,
                       and the message will not conform to the ABNF
                       described for this command. Messages with the 'E'
                       bit set are commonly referred to as an error
                       messages. This bit MUST NOT be set in request
                       messages. See section 7.2.
	   T(Potentialy re-transmitted message)
     			   - This flag is defined only for requests messages
                       sent by a Diameter client or agents.
                       This flag is used as an indication of an application layer 
                       retransmission event, (e.g. due to failover to an alternate 
                       peer, due to recovery to a primary peer or due to resending 
                       accounting records from non-volatile memory for example
                       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 MUST 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 first transmitted request arrives at the server after the 
                       retransmitted request. 
                       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 peer, due 
                       to a recovered primary peer or due to a client re-sendind a stored 
                       record from non-volatile memory for example after a reboot of the client).
                       This flag MUST NOT be set in answer messages.
         r(eserved)  - these flag bits are reserved for future use, and MUST be set to 
                       zero, otherwise an error MUST be sent to the sender.

5.5.4 Failover and Failback Procedures

Change the paragraph

When a transport failure is detected, all messages in the queue are
sent to an alternate agent, if possible. 
.....etc..

to

When a transport failure is detected, if possible all messages in the queue are
sent to an alternate agent with the "T" flag set. 

8.2 Accounting Session State Machine

Change the line of CLIENT, ACCOUNTING

Idle 		Records in storage 	Send 		PendingB
						record

to

Idle 		Records in storage 	Send 		PendingB
						record
						with "T"
						flag set

ANNEX C

Change paragraph

   In general, only the duplicate generation at failover case is some-
   thing that can be reliably detected by the Diameter client. The Diam-
   eter server is therefore responsible for the duplicate detection pro-
   cess. When real-time duplicate detection is required, this implies a
   database-like search functionality to find duplicate records. Imple-
   mentors are advised, however, that there exists ways to avoid
   expensive all-record searches. For instance, it can be usually safely
   assumed that duplicates appear within a time window of longest ima-
   ginable network partition, perhaps a day as an example. So only
   records within this time window need to be looked at. Secondly, hash-
   ing techniques or other schemes may be used to eliminate the need to
   do a full search even in this set except for rare cases.

to

  In general, only generation of duplicates due to failover or re-sending of 
  records in non-volatile storage can be reliability detected by Diameter 
  clients or agents. In such cases the Diameter client or agents can mark 
  the message as possible duplicate by setting the "T" flag. Since the 
  Diameter server is responsible for duplicate detection, it can choose to 
  make use of the "T" flag or not, in order to optimize duplicate detection. 
  Since the "T" flag does not affect interoperability, and may not be needed
  by some servers, generation of the "T" flag is required for Diameter clients 
  and agents, but may be implemented by Diameter servers. 

  As an example, it can be usually be assumed that duplicates appear
  within a time window of longest recorded network partition or device fault, 
  perhaps a day. So only records within this time window need to be
  looked at. Secondly, hashing techniques or other schemes, such as the use
  of the "T" flag in the received messages, may be used to eliminate the need 
  to do a full search even in this set except for rare cases. 

and ADD

  The following is an indicative example of how the "T" flag may be used by 
  the server to detect duplicate requests.
 
  A Diameter server may check the "T" flag of the received message to determine
  if the request is a possible duplicate. If the "T" flag is set in the request 
  message, the server searches for a duplicate within a (configurable) duplication 
  time window backward and forward. This limits database searching to those 
  records where the "T" flag is set.  In a well run network, network partitions 
  and device faults will presumably be rare events, so this approach represents 
  a substantial optimization of the duplicate detection process. 
  During failover, it is possible for the original record to be received after 
  the "T" flag marked record, due to differences in network delays experienced 
  along the path by the original and duplicate transmission. The likelihood of 
  this occurring increases as the failover interval is decreased. 
  In order to detect with relative assurance the possibly out of order duplicate 
  record, the Diameter server should use backward and forward time windows
  when performing duplicate checking for the "T" flag marked request.
  The forward time window should be at least a time period of approximately 
  TIME_WAIT.

> -----Original Message-----
> From: ext [mailto:[email-masked]]
> Sent: 17. October 2002 11:24
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AAA-WG]: Resolution of issue 372 - proposed text
> 
> 
> Hi all,
> 
> So, it seems that we are moving to consensus on this issue.
> I propose the following text for section 3, based on Jari's mail.
> Please comment.
> 
> John
> 
> 
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |      Ver      |                 Message Length                |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |R P E T r r r r|                  Command-Code                 |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                         Application-ID                        |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                      Hop-by-Hop Identifier                    |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                      End-to-End Identifier                    |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |  AVPs ...
>  +-+-+-+-+-+-+-+-+-+-+-+-+-
> 
> ... some text ....
> 
>   T, potentially retransmitted message
> 
> 	This flag is used as an 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.
> 
> 	This flag MUST NOT be set if an error answer message
> 	(about e.g. a protocol error) has been received for an 
> 	previous message. It can be used only in cases where no 
> 	answer has been received 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.
> 
> 
> Appendix C.
> 
>  The following is an example of how the T-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 T-flag.
> 
>  Diameter server may check the T-flag of the received message 
> to determine
>  if the record is a possible duplicate. With the T-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 T-flag marked 
> (i.e. T-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 T-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-flag marked
>  record is really a duplicate, out of order accounting 
> records is not an issue.
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 17 Oct 2002 09:04:32 -0400

Marco,

> first time the T flag is not to be set.

Agreed.

> refer to Session-Id and Accounting_Record_Number pairs as indicated

I agree.  Thanks for the consideration.

I have one comment, please see below.

>                        requests and detecting duplicate messages. 

> However, servers 

I think the above sentense can be moved to the Appendix.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 Oct 2002 08:58:50 -0700

[email-masked] [mailto:[email-masked]] writes:

...

> and ADD

This example sems to be specific to the application in question, and not
particularly applicable in the general case; I would leave it out of the
document.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 18 Oct 2002 09:05:08 -0700

Yoshihiro Ohba [mailto:[email-masked]] writes:

...

> I think the above sentense can be moved to the Appendix.

Or left out altogether...in the provision of the bit, we have enabled it's
usage in any fashion desired.  I would prefer that the details of this usage
be specified in documents describing protocols that use it; the base
Diameter protocol doesn't.

<text removed>