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

From: <[email-masked]>
Date: Fri, 11 Oct 2002 17:43:51 +0300

> > This proposal was already discussed sometime ago (named 
> D-bit)and was rejected because
> > the real-time duplicate detection was not seen necessary
> 
> Actually, it was rejected because the proposed solution does not work.

So, what you are saying is that existing and deployed GPRS networks 
with million of subscribers that use exactly the same technique I described
to detect duplicate, does not work. 
Very nice statement, this is like to deny the evidence.
You may need to understand better how this work.

> In practice, this is very difficult to achieve. All a 
> Diameter client can
> know is that it didn't receive an Application Layer ACK for 
> the accounting message.
> There can be Diameter agents between the client and server, so that
> failover is initiated based on "liveness" of the Diameter agent, not
> receipt of the application layer ACK. If the Diameter agent 
> is "live" (as
> indicated by receipt of DWRs) then it could be failing over 
> to a different
> accounting server, and the Diameter client will not know it -- and
> therefore would be unable to mark the messages appropriately. And of
> course, the Diameter client has no visibility into transport behavior
> anywhere along the path.

If you read better my mail you may find that I'm saying exactly the same thing.
"In addition this solution does not solve the problem 
when relay/redirect agents are between client and server."

> Even with no Diameter agents, it is possible that the server
> did send the ACK, but somehow it was never received, due to network or
> other problems. The Diameter client does not know whether it received
> a transport layer ACK for the accounting message, and whether 
> retransmission
> of the accounting message or ACK is occuring at the transport layer.

I guess these kind of failure are handled by the transport protocol
(i.e. SCTP/TCP). Reliable transport protocols such as SCTP/TCP insure 
that messages sent by application are received at the other end of the
wire (i.e. the associated peer). Only re-transmission of data chunks or
message's bytes occur, this is transparent to the application layer that
just get the message when the transport layer has successfully received
all the bytes of the message. No message duplicate occur in this
case.

> Based on the server not demonstrating "liveness" (such as 
> lack of DWRs),
> the Diameter client will failover. Since the failover time is 
> less than TIME_WAIT, it
> is conceivable that the failover connection will deliver the 
> accounting
> message (and application layer ACK) and that afterwards an application
> layer ACK will finally be received from the failing connection. So in
> practice, some sort of search is necessary in any case, within a time
> window proportional to TIME_WAIT.

Considering the D-bit approach this simply means that D=1 may arrive
before D=0. The solution for that is in the proposal I'm gonna send.

> Unfortunately, that approach is not reliable, due to the vagaries of
> transport behavior -- and it fails completely where Diameter 
> agents are
> deployed.

See above.

Br
Marco

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 11. October 2002 16:12
> To: Stura Marco (NET/Helsinki)
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: issue: real-time duplicate detection
> 
> 
> > A not so clean solution to this problem is the 
> Re-transmission AVP defined
> > in the CC Application that however introduce some challenge 
> with the management
> > of the base protocol pending message queue(i.e. CC messages 
> in queue need to be
> > deleted upon failover/failback execution to avoid their 
> re-transmission without
> > being marked with the AVP).
> 
> In practice, this is very difficult to achieve. All a 
> Diameter client can
> know is that it didn't receive an Application Layer ACK for 
> the accounting message.
> There can be Diameter agents between the client and server, so that
> failover is initiated based on "liveness" of the Diameter agent, not
> receipt of the application layer ACK. If the Diameter agent 
> is "live" (as
> indicated by receipt of DWRs) then it could be failing over 
> to a different
> accounting server, and the Diameter client will not know it -- and
> therefore would be unable to mark the messages appropriately. And of
> course, the Diameter client has no visibility into transport behavior
> anywhere along the path.
> 
> Even with no Diameter agents, it is possible that the server
> did send the ACK, but somehow it was never received, due to network or
> other problems. The Diameter client does not know whether it received
> a transport layer ACK for the accounting message, and whether 
> retransmission
> of the accounting message or ACK is occuring at the transport layer.
> 
> Based on the server not demonstrating "liveness" (such as 
> lack of DWRs),
> the Diameter client will failover. Since the failover time is 
> less than TIME_WAIT, it
> is conceivable that the failover connection will deliver the 
> accounting
> message (and application layer ACK) and that afterwards an application
> layer ACK will finally be received from the failing connection. So in
> practice, some sort of search is necessary in any case, within a time
> window proportional to TIME_WAIT.
> 
> > The CC servers implementation that decide to use the 
> Re-transmission AVP will
> > search for possible duplicate only when a request message 
> is received with this
> > AVP and not for every single received request.
> 
> Unfortunately, that approach is not reliable, due to the vagaries of
> transport behavior -- and it fails completely where Diameter 
> agents are
> deployed.
> 
> > This proposal was already discussed sometime ago (named 
> D-bit)and was rejected because
> > the real-time duplicate detection was not seen necessary
> 
> Actually, it was rejected because the proposed solution does not work.
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Oct 2002 09:04:19 -0700 (PDT)

> You may need to understand better how this work.

Since you noted yourself that the proposal does not work at all
when Diameter agents are present, I don't think we're in disagreement.

> wire (i.e. the associated peer).

Actually, they *don't* guarantee this -- that's the problem. If there is a
network partition, TCP/SCTP or any other transport protocol can't get
through. As Marshall Rose once said "you don't need reliable transport,
you need more voltage!"

All a TCP acknowledgment tells you is that the segment was received by the
TCP on the destination -- it doesn't tell you that the application at the
destination received it.

So in practice to know that the application received the data, and that
it was processed correctly, you need an application layer ACK.

> before D=0. The solution for that is in the proposal I'm gonna send.

Looking forward to it.