Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change.

From: <[email-masked]>
Date: Mon, 14 Oct 2002 19:06:57 +0300

Hi Bernard,

thanks for considering the issue.

Actually the real benefits of the D flag is that duplicate
happen very seldom, so for all the D=0 records (say 90-95% of
the records) the server can immediately process the request
and answer to the client e.g. service granted or no money.

D=1 records are statistically very few and duplicate search
only for those records do not affect the overall performance 
of the system.

Finally, your proposed text seems better than my original 
proposal. However, I'm not yet fully sure it is acceptable to
delay the processing of all the D=1 records and don't have
time to think now since I have to harry on and go back home,
I'll come back tomorrow. I guess Time_Wait may be couple of
seconds, am I right?

However proposal#2 could be just to replace the text I proposed
in Annex C that state that D falg may be used by server implementation
and specified in diameter application etc..etc

John could you make some proposal to replace my text?

Br
Marco

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 14. October 2002 16:17
> To: Loughney John (NRC/Helsinki)
> Cc: [email-masked]
> Subject: RE: [AAA-WG]: issue: real-time duplicate detection 
> and proposed
> change.
> 
> 
> > The alternatives I see are:
> >
> > 	1) Not supporting the d-bit.
> > 	2) Allow the setting of the d-bit, but either making 
> the response
> > 		implementation specific or dependent on futher 
> specification.
> > 	3) Supporting the d-bit and the behavior of responding 
> to messages
> > 		with the bit set.
> 
> We have an issue filed (372). Approach #1 would be to reject 
> the issue.
> Approach #3 appears to accept the changes requested in Issue 372. What
> does approach #2 do?
> 
> The text for Appendix C says:
> 
> "Diameter server MAY check the D flag of the received message 
> to determine
> if this record is a possible duplicate. If the D flag is set in the
> request message, the server search for the duplicate within the above
> mentioned time window. This way database search is only 
> required for those
> received records whose the D flag is set. Since in today 
> networks link failures, server
> breakdown or other similar events are very rare, this simple approach
> efficiently optimize performances of the duplicate detection process.
> It may happen that the original record is received after the 
> D flag marked
> record because they did experience different delay in their way to the
> server. For this reason it is necessary for the server to buffer the D
> flag marked records for a short time period, as an example 10 or 15
> minutes, and check every record received within this time 
> period against
> the buffered D flag marked records."
> 
> The problem is that failover can cause the accounting record 
> to be sent to
> *another* server. For example, if a proxy fails, the Diameter 
> client may
> go to another proxy, and the new proxy may set up a connection to a
> different accounting server. The approach described in the 
> last sentence
> appears to assume that the duplicate arrives at the *same* 
> server as the
> original record.
> 
> I'd suggest that the last sentence say:
> 
> "As a result, a simple approach is not foolproof, and may result in
> occasional duplicates being accepted by the system. If occasional
> duplicate records are not acceptable, then it may be 
> difficult to retain
> realtime performance. If the server cannot locate the original
> record corresponding to the D flag marked record, it is still 
> possible for
> the original to arrive later. To ensure that the duplicate is 
> detected, it
> is necessary to delay processing of the D flag marked record until
> the original record can be assured to have been received. 
> This corresponds
> approximately to TIME_WAIT."
> 
> My question is whether the above defeats the purpose of realtime
> processing.
> 
>

---

From: Pat Calhoun <[email-masked]>
Date: 14 Oct 2002 09:53:11 +0000

But what would happen if two packets were received by a Diameter server
out of order, so the first packet received had the 'D' bit set, while
the second packet did not.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Oct 2002 09:54:44 -0700 (PDT)

> the second packet did not.

That's where delaying by TIME_WAIT comes in, so that the second packet
could be processed.

> only for those records do not affect the overall performance

Question: so it wouldn't be an issue if some delay were required in
processing those records?

> I guess Time_Wait may be couple of seconds, am I right?

It varies between 30 seconds and 2 minutes.

> However proposal #2 could be just to replace the text I proposed
> in Annex C that state that D flag may be used by server implementation
> and specified in diameter application etc.

If we're only talking about a few paragraphs in Appendix C, then I'd
suggest that we should probably try to hammer this out now. However, if
using the "D" bit requires more than this, it might need to wait for
another application.

---

From: Pat Calhoun <[email-masked]>
Date: 14 Oct 2002 11:07:07 +0000

If the purpose for this "feature" is to support real-time services, such
as pre-paid calls, then I would assume that a 30-120 second delay in a
response would not be a good idea.

But perhaps I misunderstand the intention behind this feature request.

PatC

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 14 Oct 2002 15:24:34 -0400

It seems that there is an assumption that _all_ Diameter clients and
agents mandatory support 'D' bit set when failover/failback occurs.
Otherwise, the scheme will not work as is expected when
failover/failback occurs at some node that does not set 'D' bit while
the server supports D-bit handling, resulting in duplicated accounting
request undetected.

If the assumption is correct, I'm not sure if the scheme is worth
being defined in the base specification while other accounting
application does not require this scheme and more generic scheme
(i.e., hashing) may be able to solve the problem without changing the
specification.

Yoshihiro Ohba