Subject: RE: [AAA-WG]: Use of the D-Bit clarification

From: "Kuntal Chowdhury" <[email-masked]>
Date: Thu, 17 Oct 2002 11:06:33 -0500

[email-masked] wrote:

> 
> The proposal is to use the d-bit with real-time accounting to 
> assign a priority to all accounting requests where the D-bit 
> = 0, as we can safely assume this message is not a duplicate 
> request. With out it, we can never assume that an accounting request 
> is not a duplicate.
> 

Respectfully disagree. Without the T/D-bit it is possible to detect
re-transmissions as I said before. Use a sequenceID in the 
accounting messages. The billing systems are smart enough to detect
duplications based on the last successfully processed message sequenceID.

> For an accounting request where the d-bit = 1, then the 
> proposal is not to process the message in real-time, but to 
> have an optimized duplicate detection algorithm and/or 
> configurable based on service provider's needs.  

Here you are saying that D/T=1 messages wouldn't be processed in
real-time. What happens if the D/T=0 was never received at the server.
The user will get service only when the server responds back for the
D/T=1 message which was delayed (non real-time) by several seconds e.g. 
30 -120 secs at least. The user has to wait upto 2 mins to get service.
Won't that piss off the user?

> With any 
> luck, messages with the d-bit = 1 should an extremely small 
> number.  This type of mechanism is already in use in some 
> GPRS networks and shown that the mechanism is effective.
> 

We may be talking about some specific implementation here.

> Of course, one could suggest having a hashed-based look-up to 
> perform the duplicate check, but that may increase the delay 
> to the user; as well as cause additionally hardware needs 
> (memory & processor) to the service provider to ensure that 
> they are able to perform the duplicate check in real-time.
> 
> I understand that this type of functionality may not be 
> needed in traditional IP-style accounting practices; but for 
> cellular packet services, where heavy use of pre-paid 
> services is common, this is needed.
> 

Not really. pre-paid services can be deployed and used w/o this
retransmission bit in the base protocol header.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Oct 2002 20:33:16 +0300

> Won't that piss off the user?

I agree. The T bit is *only* for retransmission detection, not
for priority.

(In fact, I have previously proposed a new AVP for specifically
representing priority, so that proxies can schedule outgoing
records in priority order. This is a much more general and useful
mechanism, and can hopefully be done as a separate RFC at some
point in time.)

> retransmission bit in the base protocol header.

Yes. People have pointed out that duplicate detection can be
performed without protocol extensions as well. The Nokia folks
have stated that they believe they can do this detection faster
or with less memory if the T bit is introduced to the protocol.
*I* would choose other implementation tactics myself, but the
matter is quite important for very large deployments and I'd
hate to get into trouble later with this. Without specific
measurements to prove the case one way or the other, I'm
willing to accept an informational T bit in the header, as
long as we don't mandate any specific duplicate detection
algorithm on the server side. And I don't want any priority
meanings for this bit either, for the reasons that you Kuntal
brought up well in the above. If it turns out that most
implementations don't use the T bit, at least we can get
some useful information about the Diameter transport behaviour
by observing the number of T=1 requests.

Jari