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

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

Hi,

Jari wrote

>I believe that if we are to adopt D-bit, then it should be informative,
>and its setting be made mandatory for clients and agents, and use optional
>for servers. Question: for all apps, or just for the one that needs
>this?

I guess all applications may use the D flag scheme as any other scheme you mentioned.

> - full search every time through a db index
> - hash table based methods
> - keeping the last session ids for a user in the user 
> "account" object at the
>   server
> - heuristic methods, such as tracking correct order and checking
>   duplicates only if we appear to get out-of-order records

Would it be acceptable that all apllication may use this scheme and actually may be
defined in the application which scheme to use?

Br
Marco 

> -----Original Message-----
> From: ext Jari Arkko [mailto:[email-masked]]
> Sent: 16. October 2002 0:15
> To: Yoshihiro Ohba
> Cc: Pat Calhoun; Loughney John (NRC/Helsinki); [email-masked];
> [email-masked]; Stura Marco (NET/Helsinki); [email-masked]
> Subject: Re: [AAA-WG]: issue: real-time duplicate detection and
> proposedchange.
> 
> 
> Yoshihiro Ohba wrote:
> 
> >>>By dealing the two duplication cases separately, intermediate agent
> >>>does not have to set 'D'-bit or insert a new AVP.
> >>
> >>Not sure I completely understand. Since each intermediate hop is
> >>responsible for ack and retransmission, how could it get 
> away with not
> >>setting the 'D' bit (or the new AVP for that matter)?
> > 
> > 
> > That part (i.e., duplicated requests based on normal
> > failover/failback) can be detected based solely on the 
> combination of
> > End-to-End Identifier and Origin-Host AVP (perhaps with using either
> > time-based window or hash table at Diameter servers, but without 
> > D-bit in the header).
> 
> *All* duplication can be detected based on server implementations.
> Some known methods:
> - full search every time through a db index
> - hash table based methods
> - keeping the last session ids for a user in the user 
> "account" object at the
>   server
> - heuristic methods, such as tracking correct order and checking
>   duplicates only if we appear to get out-of-order records
> The current debate is about the speed and efficiency of various
> ways of doing this, and whether the D-bit helps the server in making
> the duplicate-or-not decision.
> 
> There's two kinds of duplicate detection, based on end-to-end id and
> session id, and based on the session-id and accounting-record-number.
> Same techniques can be applied to both, however.
> 
> I believe that if we are to adopt D-bit, then it should be 
> informative,
> and its setting be made mandatory for clients and agents, and 
> use optional
> for servers. Question: for all apps, or just for the one that needs
> this?
> 
> All duplicate detection should also cover the following cases:
> - Regular failover duplicate from a client.
> - Failover from an agent to the server. And here we need
>   to worry about invalidating any signatures; cmssec isn't
>   done yet but I think we need to sign not just the AVPs
>   but also include the command code and the bits.
> - Reboot and then resend acct records from nvm. This needs
>   care with the d-bit, since the rebooted server must not
>   send d=0 records as they may have been already sent.
> 
> In general, methods based on protocol information (such as the d-bit)
> provide duplicate detection that relies on the client and agents
> to perform it correctly. Implementation and configuration problems,
> for instance, can't be fixed on the server side in this case. It is
> debatable, however, whether this is a requirement. 
> (Server-only approaches
> to duplicate detection do not rely on the other nodes.)
> 
> Jari
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Oct 2002 13:53:32 +0300

> defined in the application which scheme to use?

I view this rather as an implementation decision on the server side (I would
use something else but that's just my own preference). I can agree, however,
that the clients & agents can set an informative bit on when they (a) know
that this is an app-layer retransmission or (b) don't know if this has been
transmitted before. We also need to be careful about the semantics of of the
bit defined in the document; perhaps we shouldn't say much more than (a) & (b)
above. And maybe we need to warn the reader that they can't detect duplicates
only based on the bit (also need to look for D=1, D=0 order; configuration
errors, etc). If there's a need to say more, maybe that's up to implementations
or profiles in e.g. 3GPP specifications.

Jari