Internet DRAFT - draft-asveren-dime-dupcons

draft-asveren-dime-dupcons






Network Working Group                                         T. Asveren
Internet-Draft                                              Ulticom Inc.
Intended status: Informational                           August 30, 2006
Expires: March 3, 2007


                   Diameter Duplicate Detection Cons.
                   draft-asveren-dime-dupcons-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 3, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Diameter transport mechanism relies on storing data about received
   requests to detect duplicate requests.  This document discusses
   implementation and deployment considerations regarding this
   functionality.







Asveren                   Expires March 3, 2007                 [Page 1]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Reasons for Duplicate Requests  . . . . . . . . . . . . . . . . 3
     2.1.  Restart of Client . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Restart of Intermediate Node  . . . . . . . . . . . . . . . 3
   3.  Arrival of Retransmission Before Original Request . . . . . . . 4
   4.  Duplicate Detection Implementation Guidelines . . . . . . . . . 4
     4.1.  Buffering of Requests with T-bit not Set  . . . . . . . . . 4
     4.2.  Buffering of Requests with T-bit Set  . . . . . . . . . . . 6
     4.3.  End-to-End Id Selection . . . . . . . . . . . . . . . . . . 6
     4.4.  Retransmission of First Request in a Session  . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

































Asveren                   Expires March 3, 2007                 [Page 2]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


1.  Introduction

   Diameter Base Protocol[1] defines the transport mechanism to be used
   for sending/receiving requests/answers.  The capability to detect
   duplicate requests is also included in this mechanism to prevent
   multiple processing of the same request.  This capability relies on
   storing data about received requests on the server.  Origin-Host AVP
   and End-to-End Identifiers of received messages need to be stored for
   duplicate detection.  If the application is unable to regenerate the
   exact answer which was sent for the initial request, the answer
   message itself needs to be stored as well.


2.  Reasons for Duplicate Requests

   Duplicate requests may be received due to client or intermediate node
   restarts.

2.1.  Restart of Client

   When a client fails, it may retransmit requests, which were sent
   before the failure but for which no corresponding answer has been
   received yet.  This may cause a server to receive the same request
   twice.


    +-------+               +-------+
    |       |---(1)Req----->|       |
    |Client |(2)X<--Ans-----|Server |
    |       |---(3)Req----->|       |
    |       |<--(4)Ans------|       |
    +-------+               +-------+


         Figure 1: Retransmission of Request After Client Restart

   (1) Client sends a request, request is received by server.
   (2) Client goes down but before this is detected by the server,
   server sends back the corresponding answer.
   (3) Client restarts, and resends the request with T-bit set.

2.2.  Restart of Intermediate Node

   When an intermediary node in the path from client to server fails,
   the node before it needs to retransmit requests, for which no
   corresponding answer has been received yet.





Asveren                   Expires March 3, 2007                 [Page 3]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


    +------+          +-------+          +-------+
    |Client|-(1)Req-->|Relay  |-(2)Req-->| Server|
    |      |          |Agent 1|(3)X<-Ans-|       |
    +------+          +-------+          +-------+
      ^   |                               ^  |
      |   |           +-------+           |  |
      |   +--(4)Req-->|Relay  |-(5)Req----+  |
      +-(7)Ans--------|Agent 2|<-----(6)Ans--+
                      +-------+

       Figure 2: Retransmission of Request After Relay Agent Failure

   (1) Client sends the request to Relay Agent 1.
   (2) Relay Agent 1 forwards the request to server.
   (3) Relay Agent 1 goes down and before the server can detect it, the
   server sends the answer.
   (4) Client detects that Relay Agent 1 went down and retransmits the
   request to Relay Agent 2.
   (5) Relay Agent 2 forwards the request to the server.
   (6) Server sends the answer message to Relay Agent 2.
   (7) Relay Agent 2 forwards the answer to the client.


3.  Arrival of Retransmission Before Original Request

   A retransmitted request may arrive to the server before the
   corresponding original request.  This may happen due to requests
   taking different paths in the diameter or IP networks.  Because of
   the latter, even a client and server, which are directly connected
   from diameter point of view may observe retransmitted requests
   arriving before the original ones, if the client restarts.


4.  Duplicate Detection Implementation Guidelines

4.1.  Buffering of Requests with T-bit not Set

   Origin-Host AVP and End-to-End Identifier for all requests received
   by a server MUST be saved, until it is guaranteed that no
   corresponding retransmission will be received.  If the server is
   unable to regenerate the exact answer which was sent as response to
   the original request, this answer message MUST be saved as well.

   Diameter base protocol does not provide a mechanism, by which a
   server can detect that an answer message has been received by the
   client, which sent the corresponding request message.  This would
   have indicated the server that buffered information for that request
   could be deleted because from that moment on no retransmissions for



Asveren                   Expires March 3, 2007                 [Page 4]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


   that request are possible.

   Implementations MAY configure a value for the maximum time, after
   which no retransmission of a request will arrive, e.g. maximum
   expected downtime for any client + maximum network delay.  Although
   such a value could be only a guess and needs to be configured
   generously to prevent non-detection of retransmissions, it still MAY
   be used to decide when buffered information can be deleted.

   Client failures could be hardware related, where replacement of
   equipment may be necessary.  Such cases could result downtimes of a
   few hours.  This would cause buffering of large amounts of data on
   servers.  For example consider a server which handles 1000 messages
   per second, which can't regenerate answers:
   length of End-to-End Identifier: 4 bytes
   average answer length: 280 bytes
   average Origin-Host AVP length: 16 bytes
   maximum buffering time: 2 hours
   amount of data to be buffered: 1000*7200(4+16+280) ~ 2 GBytes

   Especially with larger answer messages, amount of data to be buffered
   can get much bigger.  Usually, that type of memory requirement is
   considered undesirable.  Implementation MAY choose to store this
   information in non-volatile memory but frequent writes to non-
   volatile memory can cause a significant performace penalty.

   Applications MAY use new requests arriving from a peer as indirect
   acknowledgements to decrease the amount of data buffered for
   duplicate detection, if a value can be configured as the maximum end-
   to-end delay in the Diameter network.  Each new request MAY be
   interpreted as that answers sent 2*maximum end-to-end delay ago are
   received by the originator of the request, and buffered data
   associated with the corresponding request can be deleted.  This
   technique could decrease memory requirements for duplicate detection
   significantly but it should be noted that it MAY cause failure to
   detect duplicates, if maximum end-to-end delay is not choosen
   carefully.

   Applications MAY try to guess end-to-end delay between two peers
   dynamically.  This can be achieved by sending an invalid message to
   other peers and measuring the time difference between sending the
   message and receiving corresponding error answer.  By considering
   multiple measurements and providing a generous buffer, the calculated
   value can be utilized while using requests as implicit
   acknowledgements.






Asveren                   Expires March 3, 2007                 [Page 5]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


4.2.  Buffering of Requests with T-bit Set

   Information related with requests with T-bit set MUST be buffered as
   well, if the original request is not received yet, because it is
   possible for a retransmission to arrive before the corresponding
   original request.  In such a case, the original request MUST be
   treated as a duplicate.

   Information buffered for requests with T-bit SHOULD be buffered as
   long as the expected maximum network delay.  Usually this value could
   be around a few seconds and considering that requests with T-bit set
   are rare, it is not expected that memory requirements will be high.

4.3.  End-to-End Id Selection

   End-to-End Identifier is important from duplicate detection point of
   view because it uniquely identifies requests sent by a specific peer.

   Diameter base protocol mandates that End-to-End Id must be unique at
   least for a period of 4 minutes.  This MAY cause false duplicate
   detections, if a client goes down for more than 4 minutes, because a
   retransmission of a request from the previous boot-cycle and a new
   request MAY have the same End-to-End Id.

   Considering that End-to-End Id is 32-bits, the duration of its
   uniqueness can be generated as a function of average number of
   messages per second and minimum restart time.  Enough bits need to be
   allocated to distinguish between each message in a boot cycle and
   between boot cycles.

   The uniqueness period t_u MUST satisfy the following inequality:
   32 >= ceiling[log_2(msg_rate*t_u)] + ceiling[log_2(t_u/min_restart)]

   For example:
   message rate: 500 msg/sec min_restart: 1 sec
   A uniqueness period of 1035 seconds could be guaranteed:
   ceiling[log_2(500*1035)] + ceiling[log_2(1035)] =
   19 + 11 = 30 < 32

   Even if uniqueness of End-to-End Id is guaranteed for more than 4
   minutes, as long as uniquenees period is less than the maximum
   expected downtime, false duplicate detections MAY occure but longer
   uniqueness periods statistically will decrease the probability of
   that to happen.

   Implementations MAY consider Session-Id as well to decrease the
   possibility of false duplicate detections, in addition to End-to-End
   Id and Origin-Host AVP.



Asveren                   Expires March 3, 2007                 [Page 6]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


4.4.  Retransmission of First Request in a Session

   First requests in a session are different than the subsequent ones,
   because the first requests MAY NOT contain Destination-Host AVP.  In
   such a case, the request is routed based on Destination-Realm AVP and
   Application-Id.

   Considering that information about request are buffered at the server
   where they have been sent, retransmission of a request SHOULD be sent
   to the same server so that duplicate detection can be performed.  To
   guarantee this type of behavior, all Diameter nodes SHOULD guarantee
   that all requests with the same End-to-End Id are sent to the same
   next hop.


5.  IANA Considerations

   This document does not require any action from IANA.


6.  Security Considerations

   This document does not introduce new security considerations and the
   considerations given in RFC3588 [1] do apply.


7.  Acknowledgments

   The author would like to thank David Lehmann for his invaluable
   comments.


8.  Normative References

   [1]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.


Author's Address

   Tolga Asveren
   Ulticom Inc.
   1020 Briggs Road
   Mount Laurel, NJ, 08054
   USA

   Email: asveren@ulticom.com




Asveren                   Expires March 3, 2007                 [Page 7]

Internet-Draft     Diameter Duplicate Detection Cons.        August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Asveren                   Expires March 3, 2007                 [Page 8]