Subject: [AAA-WG]: Question on Diameter behavior in Failure cases

From: [email-masked]
Date: Wed, 5 Sep 2001 11:04:07 +0300

Hi Pat,

As you can imagine, I've been doing some studying on the
reliability aspects of Diameter.

One question I have is what happens if a Diameter client goes 
down while sending messages, before getting a response to a 
pending message, when there is no secondary peer?

The base protocol draft text says: 

5.1  Peer Connections

   Although a Diameter node may have many possible peers that it is able
   to communicate with, it may not be economical to have an established
   connection to all of them. At a minimum, a Diameter node SHOULD have
   an established connection with a primary and secondary peer, and MAY
   have additional connections, if it is deemed necessary.

Does that imply that a Diameter node may not ALWAYS have a
secondary or additional connections available.

In that case, if the Diameter client stops temporarily getting 
answer messages (and does not have an alternate agent to send 
the payload packet), the primary peer may recover (after a boot,
for example). Then the following problem arises:

Should the Diameter client re-send the pending payload
message to its original (& now recovered) primary (& only) peer 
node, as the client does not know if the packet had been
properly received went sent before the failure.

It seems that this case a solution could be offered by the 
by marking the the packet 'possibly duplicated' (see my
proposal sent yesterday for usage of a 'D' bit in the Diameter 
header) since the receiving primary (and only) peer node could 

  a) check the 'D' marked packet against being a packet
     already received.
  b) forward the 'D' marked packet even towards the
     end system (Diameter Server), as the final destination
     node would anyway be responsible to verify that there
     are no duplicates and from the 'D' bit it would clearly
     note that it must check that packet (by comparing the
     End-to-End Identifiers of the marked packet(s)).

This way we could get the one-peer-agent-only cases
to work okay.  Additionally it supports the case when the 
connection to the (only) recipient peer agent goes temporarily 
to the SUSPECT state (or the connection is temporarily closed) 
and is then again established in the OKAY state.

Comments?
John

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 5 Sep 2001 07:08:11 -0700 (PDT)

> pending message, when there is no secondary peer?

If the NAS goes down, you will have a AAA failure whether there
are secondary servers or not. The way to handle that kind of failure
is via clustering technology (some NASes already support this today)
so that the connection can be migrated to another NAS. Diameter can't help
with this. 

> secondary or additional connections available.

Failover protection is not mandatory. But if you want high
availability it is a good idea. 

> for example). Then the following problem arises:

I'm confused. You were initially talking about a *client* failure. Now you
are talking about *server* failures. If the primary server fails and there
is no alternate, then availability is compromised. Again, there isn't
much that Diameter can do about that. 

> properly received went sent before the failure.

This points out that failure scenarios can result in duplicates, not only
to different servers, but also to the same server. That is what the
e2e session identifier was created to handle. In the case of accounting,
this should be sufficient to deal with a duplicate accounting record. 

In the case of authentication/authorization, I'm not sure that there is a
problem. You'll just get a new response. The only problem that could have
arisen is if the server wrote something about the session to stable
storage before responding, and *then* the connection failed (such as
incrementing the simultaneous session count). In that case, when the
server comes up again, it will have incorrect information in its database. 

The solution to this is for the server to *not* write session info to
stable storage until it receives the equivalent of an application-layer
ACK from the NAS. There is no app-layer ACK of an authentication response
in Diameter, because the Accounting Request largely serves this function. 

> header) since the receiving primary (and only) peer node could 

I don't think that this is necessary, if the advice above is followed. Can
you come up with a scenario in which a problem would be caused by receipt
of a duplicate authentication packet?