Internet DRAFT - draft-harada-xmpp-srv-record-query

draft-harada-xmpp-srv-record-query






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 <iq/> get over the
   stream from the client to the server.

3.2 IQ-get message 

   Example 1.  IQ-get message(client - server)

   <iq from="alice@wonderland.lit"
       id="ac4cf"
       to="wonderland"
       type="get">
     <query xmlns="jabber:iq:SRVrecord" />
   </iq>

   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)

   <iq from="wonderland.lit"
       id="ac4cf"
       to="alice@wonderland.lit"
       type="result">
     <query xmlns="jabber:iq:SRVrecord">
       <item name="sv1.wonderland.lit" priority='10' weight='10'/>
       <item name="sv2.wonderland.lit" priority='10' weight='10'/>
       <item name="sv3.wonderland.lit" priority='20' weight='0'/>
     </query>
   </iq>

   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)
 
   <iq from="wonderland.lit"
       id="ac4cf"
       to="alice@wonderland.lit"
       type="error">
     <body>Sorry! Not support to SRV record query!</body>
     <error code='404' type='cancel'>
      <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     <error/>
   </iq>

   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)
  
   <iq from="wonderland.lit"
       id="ac4cf"
       to="alice@wonderland.lit"
       type="result">
     <query xmlns="jabber:iq:SRVrecord">
       <item name="sv1.wonderland.lit" priority='10' weight='10' wait='5'/>
       <item name="sv2.wonderland.lit" priority='10' weight='10' wait='5'/>
       <item name="sv3.wonderland.lit" priority='20' weight='0' wait='5'/>
     </query>
   </iq>

   Example 5. IQ-result message (server - client)
  
   <iq from="wonderland.lit"
       id="ac4cf"
       to="alice@wonderland.lit"
       type="result">
     <query xmlns="jabber:iq:SRVrecord">
       <item name="sv1.wonderland.lit" priority='10' weight='10' wait='30'/>
       <item name="sv2.wonderland.lit" priority='10' weight='10' wait='30'/>
       <item name="sv3.wonderland.lit" priority='20' weight='0' wait='30'/>
     </query>
   </iq>


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]