Internet Engineering Task Force Akari Harada Internet-Draft Nobuo Ogashiwa Intended Status: Informational Maebashi Kyoai Gakuen College Expires: July 31, 2012 Hirotaka Sato Keio Univ. Yoshihiro Suzuki D3 Communications January 29, 2012 SRV record query extension for XMPP draft-harada-xmpp-srv-record-query-00 Abstract According to RFC 6120, XMPP clients should use SRV records within the connection establishment process to servers. There are two purposes for using SRV records. The one is to advertise the FQDN of at least one server to clients to establish an initial TCP connection. The other purpose is to advertise at least two or more FQDN with priority and weight information to clients to accomplish load balancing, a redundant server environment and so on. However, most standard resolver libraries of recent client OSs don't support SRV record resolution. Furthermore, many DNS hosting services also don't support SRV records. This document proposes a solution that enables a server and client to achieve load balancing and a redundant server environment in case SRV records cannot be used. Moreover, the proposed IQ-result message can include minimum wait time to reconnect, allowing clients to reconnect after the most suitable wait time avoiding congestion. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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." Harada, et al. Expires July 31, 2012 [Page 1] Internet-Draft XMPP SRV Record Query January 2012 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 July 31, 2012. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Client Resolver . . . . . . . . . . . . . . . . . . . . . . 3 2.2 DNS Hosting Service . . . . . . . . . . . . . . . . . . . . 3 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Overview of the solution . . . . . . . . . . . . . . . . . 4 3.2 IQ-get message . . . . . . . . . . . . . . . . . . . . . . 4 3.3 IQ-result message. . . . . . . . . . . . . . . . . . . . . . 4 3.4 IQ-error message . . . . . . . . . . . . . . . . . . . . . . 5 4. Reconnection Policy Information . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1 Normative References . . . . . . . . . . . . . . . . . . . 6 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 Harada, et al. Expires July 31, 2012 [Page 2] Internet-Draft XMPP SRV Record Query January 2012 1. Background In section 3 "TCP Binding", RFC 6120 specifies that XMPP clients should use DNS SRV records to connect to servers. There are two purposes for using SRV records within the connection establishment process. They are as follows: (A.1) To inform initiating entities of at least one server hostname for TCP connection establishment. (A.2) To inform initiating entities of at least two or more server hostnames with priority and weight information to achieve load-balancing or a redundant server environment. 2. Problems However, at present, there are many cases of incompletely supported SRV records in both clients and servers. 2.1 Client Resolver Many of the deployed DNS resolver implementations which are implemented as a standard library on popular client OSs support 'A record' and 'AAAA record' resolution but don't support 'SRV record' resolution. If a standard library doesn't support SRV record resolution, client software has to have the original code of resolver functions. However, implementing original resolver functions can result in serious implementation costs. There are some solutions relating to (A.1), which are A record resolutions or 'hardcode' of the server hostname. However, there are no solutions relating to (A.2) described in the above section. 2.2 DNS Hosting Service There are many DNS Hosting Services and many of them don't support SRV record registration via a web-based user interface. In this case, to accomplish (A.2), internal redundancy technologies like internal clustering technologies will be required. However, establishment of such internal redundancy environments can result in serious operation costs. Harada, et al. Expires July 31, 2012 [Page 3] Internet-Draft XMPP SRV Record Query January 2012 3. Proposed Solution 3.1 overview of the solution This section describes a new info/query stanza as a solution for the above problem. This is done by sending an get over the stream from the client to the server. 3.2 IQ-get message Example 1. IQ-get message(client - server) The client requests the server for information similar to a SRV record. If the server supports similar SRV record information, it MUST return an IQ-result with that information to the client. 3.3 IQ-result message Example2. IQ-result message (server - client) If the server does not support any SRV record information, the server returns an error message to the client. Harada, et al. Expires July 31, 2012 [Page 4] Internet-Draft XMPP SRV Record Query January 2012 3.4 IQ-error message Example3. IQ-error message (server - client) Sorry! Not support to SRV record query! Other error conditions defined in RFC 6120 could also be returned if appropriate. 4. Reconnection Policy Information The reconnection algorithm when an XMPP server goes offline unexpectedly is specified as follows in section 3.3 of RFC 6120. "It can happen that an XMPP server goes offline unexpectedly while servicing TCP connections from connected clients and remote servers. Because the number of such connections can be quite large, the reconnection algorithm employed by entities that seek to reconnect can have a significant impact on software performance and network congestion. If an entity chooses to reconnect, it: o SHOULD set the number of seconds that expire before reconnecting to an unpredictable number between 0 and 60 (this helps to ensure that not all entities attempt to reconnect at exactly the same number of seconds after being disconnected). o SHOULD back off increasingly on the time between subsequent reconnection attempts (e.g., in accordance with "truncated binary exponential backoff" as described in [ETHERNET]) if the first reconnection attempt does not succeed." The purpose of this algorithm is to avoid congestion by a large number of clients reconnect to the XMPP server simultaneously. However, congestion can be avoided without the above algorithms if the extension proposed in this document is used. This can be accomplished by informing a different 'minimum reconnection wait time' to each client. Furthermore, by informing a short 'minimum reconnection wait time' to lively clients and informing a long 'minimum reconnection wait time' to less lively clients, efficiency can be improved. The following example shows a case where the server allows client A to reconnect after 5 seconds and allows client B to reconnect after 30 seconds. Harada, et al. Expires July 31, 2012 [Page 5] Internet-Draft XMPP SRV Record Query January 2012 Example 4. IQ-result message (server - client) Example 5. IQ-result message (server - client) 5. Security Considerations This document has no requirement for a change to the security models within associated protocols. 6. IANA Considerations TBD 7. References 7.1. Normative References [RFC6120] P. Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core", March 2011 [RFC2782] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV) ", February 2000 Harada, et al. Expires July 31, 2012 [Page 6] Internet-Draft XMPP SRV Record Query January 2012 7.2. Informative References Authors' Addresses Akari Harada Maebashi Kyoai Gakuen College 1154-4 Koyahara-machi Maebashi City, Gunma Pref JAPAN 379-2192 EMail: harada09@c.kyoai.ac.jp URI: http://www.kyoai.ac.jp/ Nobuo Ogashiwa Maebashi Kyoai Gakuen College 1154-4 Koyahara-machi Maebashi City, Gunma Pref JAPAN 379-2192 EMail: ogashiwa@c.kyoai.ac.jp URI: http://www.kyoai.ac.jp/ Hirotaka Sato Keio Univ. 5322 Endo, Kanagawa, Japan 252-0812 Email: satu@sfc.wide.ad.jp Yoshihiro Suzuki D3 Communications 1-18-31 Tamagawa-Gakuen Machida City, Tokyo Japan 194-0041 Email: hiro.suzuki@d3communicaitons.jp Harada, et al. Expires July 31, 2012 [Page 7]