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

From: <[email-masked]>
Date: Thu, 17 Oct 2002 11:24:18 +0300

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: Bernard Aboba <[email-masked]>
Date: Thu, 17 Oct 2002 04:42:26 -0700 (PDT)

>  If the duplicate record is not found in the backward and

Why would a Diameter agent need to do this check, rather than the
accounting server?

>  It could then be left to the end system to compare the possible

This paragraph makes it sound like Diameter supports some kind of
clustering capability. It's the *database* that is the single logical
entity, not the servers.

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

Not sure why the window is TIME_WAIT in the backward direction. In the
case of a device that had a fault and was subsequently repaired (e.g.
power supply went out, ops took several hours to make the repairs), it is
possible that the duplicate resulting from the device coming up again and
dumping its non-volatile storage could occur *hours* after the original
was received. It would be great if all faults were resolved within
TIME_WAIT, but I don't think most ops groups would agree to be held to
that standard :)

I'd also note that in this case, the device would need to be smart enough
to know that any accounting records found in non-volatile memory on boot
need to be set with the "T" bit.

Assuming this is done, in the forward direction, the window can be
smaller, because a original should only arrive *before* the duplicate in
the case of failover. While the original connection is "suspect", the
Diameter client may have switched over to the new server, and according to
the transport state machine, the time between going into the "SUSPECT"
state and closing the connection is Tw + TIME_WAIT, assuming that no
heartbeat is detected. If a heartbeat is detected, then the
original connection might remain up for considerably longer than this. So
the time to look into the future is really until TIME_WAIT after the
old connection is closed.

This could be an indeterminate amount of time; to make it determine would
require eliminating the SUSPECT state, which is not something that we want
to do at this time.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 17 Oct 2002 04:50:54 -0700 (PDT)

I'd also add that adding the "T" bit to all records sent from storage is
not correct. The term "storage" is used in the accounting server whenever
there is a failure to transmit -- I don't think that it implies that
failover has occurred. So this would cause many, many more records to be
sent with the "T" bit set.

---

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

> I propose the following text for section 3, based on Jari's mail.

Why "potentially retransmitted"?  I would think that this must be
deterministic...

> 	request or accounting record contained in the request for the first time,

In order to assure that only retransmissions have the flag set, I would
change this MAY to MUST.

> 	client or agent is unable to assure that it is the first such request,

Does this mean that a stateless agent would always set the flag before
forwarding?

> 	previous message.

Change "an" to "the", I think; otherwise, this could be interpreted as "if a
protocol error ever happens, never set the 'T' bit again"

>     It can be used only in cases where no