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]