Subject: RE: [AAA-WG]: Issue 128: duplicate packet detection failure case

From: [email-masked]
Date: Tue, 4 Sep 2001 17:59:09 +0300

Hi Pat,

Sorry for the delay in responding - I have been quite
busy - I have another document that just finished
last call.  I was a bit rushed when I submitted
the issue for Diameter, it had actually 2 different parts that 
are easiest to consider separately:

1) Marking of the possibly duplicated messages.
2) Removal of duplicate messages.

Step 1 is a minimal functionality for enabling the
duplicate message checking to be efficient as possible.
The Diameter client knows (after hearing no response) 
that it is sending the message a 2nd (or 3rd etc.)
time (either to the original peer node or an alternate node).

Enhancing the efficiency of checking is the main
benefit but it may improve a bit the reliability too. 
It also improves the reliability somewhat since the
Diameter client has in End-to-End Identifier only 12
low order bits of the local time when booting. That is
4096 seconds which is a bit over a hour.

This means that with very bad luck, a Diameter client
that goes down and wakes up after 4096 seconds MAY send
a message with the same End-to-End Identifier, taking from 
non-volatile memory an earlier sent (but not yet answered) 
pending message and produces a duplicate. Unless, it has 
this capability to mark with 'D' bit that the pending message 
now resent may be a duplicate.)
  
Step 2 is a solution where in addition to the minimal
solution of marking the possibly duplicated packets, the
duplicates are also removed form the network as quickly
as possible, with minimal amount of double-checking.

This mail presents only a simplified way of step 1, as it
can be used also as a stand-alone feature (just an additional 
flag bit in the Diameter header). Please review the following
description, it would help the Diameter Server to avoid
the obligation to do a mandatory cross check every single
received request message - which should save on processing.

The needed small changes for the step 1)
(marking of possibly duplicated packets) to the
draft-ietf-aaa-diameter-07.txt are the following:

3.0  Diameter Header

...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E r r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

would be:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R P E D r r r r|                  Command-Code                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and

         E(rror)     - If set, the message contains a protocol error,
                       and the message will not conform to the ABNF
                       described for this command.  Messages with the
                       'E' bit set is commonly referred to as an error
                       message. This bit MUST NOT be set in request
                       messages. See section 7.2.
         r(eserved)  - this flag bit is reserved for future use, and
                       MUST be set to zero.

would get one new flag bit 'D':

         E(rror)     - If set, the message contains a protocol error,
                       and the message will not conform to the ABNF
                       described for this command.  Messages with the
                       'E' bit set is commonly referred to as an error
                       message. This bit MUST NOT be set in request
                       messages. See section 7.2.
         (possibly) D(uplicated)
                     - If set, the message is possibly a duplicate,
                       and must be later checked by a recipient node
                       if it really is a duplicate. If sending a
                       message for first time, this bit MUST be cleared.
                       This bit MUST NOT be set if an answer message
                       (about e.g. a protocol error) has been got for
                       an earlier similar message, it is used only
                       in cases where no answer has been got from the
                       primary agent for a message and the message is
                       sent again (e.g. due to failover, to an
                       alternate agent).
         r(eserved)  - this flag bit is reserved for future use, and
                       MUST be set to zero.

In:

5.5.4  Failover/Failback Procedures

...
   It is important to note that multiple identical request or answer MAY
   be received as a result of a failover. The End-to-End Identifier
   field in the Diameter header along with the Origin-Host AVP MUST be
   used to identify duplicate messages.

the above paragraph would be amended as:

   It is important to note that multiple identical request or answer MAY
   be received as a result of a failover. The possibly-Duplicated flag
   MUST be set by the Diameter client node that performs failover, to
   mark those packets that it had sent with no answer message coming from
   the primary agent, and which it therefore forwards to an alternate
   node. The final destination node of a message MUST check those
   messages that have the 'D' bit set, if they can be identified as
   actually duplicated messages. The intermediate nodes MAY check
   the messages with the 'D' bit set, if they can be identified
   as duplicate messages. The End-to-End Identifier field in the
   Diameter header along with the Origin-Host AVP MUST be used to
   identify duplicate messages among the marked possibly duplicated
   messages.

and in:

9.4  Fault Resilience

...
   Diameter peers acting as clients MUST implement the use of failover
   to guard against server failures and certain network failures.
   Diameter peers acting as agents or related off-line processing
   systems MUST detect duplicate accounting records caused by the
   sending of same record to several servers and duplication of messages
   in transit. This detection MUST be based on the inspection of the
   Session-Id and Accounting-Record-Number AVP pairs.

paragraph would get one sentence to its end:

....
   Diameter peers acting as clients MUST implement the use of failover
   to guard against server failures and certain network failures.
   Diameter peers acting as agents or related off-line processing
   systems MUST detect duplicate accounting records caused by the
   sending of same record to several servers and duplication of messages
   in transit. This detection MUST be based on the inspection of the
   Session-Id and Accounting-Record-Number AVP pairs. The inspection
   MUST be performed at least for such records that arrived to the
   Diameter peer in messages having the 'D' bit set.

br,
John

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 6 Sep 2001 07:43:15 -0700

> 1) Marking of the possibly duplicated messages.

but what's the point? How do you know whether the first copy was received? What
about the second copy when sending the third? In any case, duplicate checking 
beyond the 'D' bit is necessary.

> 4096 seconds which is a bit over a hour.

I'd argue that if a message takes a bit over an hour to make it to the
server, then the response is moot (and something in the network is broken).

> now resent may be a duplicate.)

right, but now you have the same problem, right? If a client reboots twice,
exactly 4096 seconds apart, then the IDs will be similar, and the 'D' bit
becomes irrelevant since once doesn't really know if it is for the first hour,
the second hour, etc.

So I am convinced that the protocol is fine as-is, and duplicate checks is
a little more complicated than just setting a 'D' bit in a header.

> draft-ietf-aaa-diameter-07.txt are the following:

well, I don't have a particular issue with the above proposed text, but do
question it's need. I'm willing to listen to the WG on this one.

PatC