Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
draft-thomson-beep-async-02

Network Working Group                                         M. Thomson
Internet-Draft                                                    Andrew
Intended status: Standards Track                          March 23, 2009
Expires: September 24, 2009

Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
                      draft-thomson-beep-async-02

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."

   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 September 24, 2009.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
   framework for the development of application protocols.  This
   document describes an BEEP feature that enables asynchrony for

Thomson                Expires September 24, 2009               [Page 1]
Internet-Draft         Asynchronous BEEP Channels             March 2009

   individual channels.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions used in this document . . . . . . . . . . . . . . . 4
   3.  Asynchronous BEEP Channels  . . . . . . . . . . . . . . . . . . 4
     3.1.  Asynchronous Feature  . . . . . . . . . . . . . . . . . . . 4
     3.2.  Starting an Asynchronous Channel  . . . . . . . . . . . . . 5
     3.3.  Asynchronous Channel Behaviour  . . . . . . . . . . . . . . 6
   4.  Alternatives  . . . . . . . . . . . . . . . . . . . . . . . . . 7
     4.1.  Increasing Throughput . . . . . . . . . . . . . . . . . . . 7
     4.2.  Asynchrony in the Application Protocol  . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9

Thomson                Expires September 24, 2009               [Page 2]
Internet-Draft         Asynchronous BEEP Channels             March 2009

1.  Introduction

   The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
   framework that manages many of the aspects necessary in developing an
   application protocol: framing, encoding, privacy, authentication and
   asynchrony.  However the asynchrony provided by BEEP is limited to
   asynchrony between channels; replies to messages sent on any channel
   are strictly ordered.

   Serial processing behaviour is desirable for a range of applications.
   However, serial processing is less suitable for applications that
   rely more heavily on asynchrony.  In particular, if a response takes
   a significant amount of time to create, the channel is effectively
   blocked until the request has been processed and the response sent.
   Pipelining only ensures that network latency does not add to this
   time; subsequent requests cannot be processed until a response is
   made to the first request.

   Asynchronous applications require a protocol that is able to support
   a large number of concurrent outstanding requests.  The analogy of a
   channel as a thread does not scale to the large number of threads
   used in modern systems.  Modern applications regularly have large
   numbers of concurrent processing threads.  Thus, a better way of
   multiplexing large numbers of concurrent requests is required.

   This document describes an BEEP feature, an extension to BEEP, that
   enables the creation of an asynchronous channel.  An asynchronous
   channel is a channel where response ordering is not fixed to the
   order of the requests sent by the client peer.  An asynchronous
   channel is identical to other channels, using unmodified framing;
   only requests may be processed in parallel and responses may be sent
   in any order.

   An asynchronous channel enables the efficient use of a single channel
   for multiple concurrent requests.  There is no impact on requests
   arising from the timing of responses to other requests.  The
   requesting peer can process responses to the requests it sends as
   they come available; similarly, the serving peer can take advantage
   of parallel processing without artificial constraints on the order of
   responses.

   Asynchronous channels allow for greater throughput where the serving
   peer requires any time to process requests.  This is particularly
   relevant where the serving peer needs to perform lengthy computations
   or make network-based requests as a part of servicing the request.

   BEEP feature negotiation is used to ensure that both peers are
   mutually willing to create asynchronous channels.  A means for

Thomson                Expires September 24, 2009               [Page 3]
Internet-Draft         Asynchronous BEEP Channels             March 2009

   establishing an asynchronous channel is described.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  Similar to
   in [RFC3080], these words are written in lower case; this document
   refrains from unnecessary shouting.

3.  Asynchronous BEEP Channels

   This document defines a BEEP feature that enables the use of
   asynchronous channels.  An asynchronous channel is a BEEP channel
   that is not subject to the restrictions of Section 2.6.1 of [RFC3080]
   regarding ordering of responses; requests can be processed and
   responded to in any order by the serving peer.

   Asynchronous channels use the "msgno" element of the BEEP frame
   header to correlate request and response.  Regular BEEP channels do
   not use "msgno" for request/response correlation, contrary to what
   might be inferred by the presence of the parameter.  In a regular
   BEEP channel, the "msgno" only serves as an means of checking for
   protocol errors.

   Asynchronous channels are not suitable for applications where state
   established by requests is relied upon in subsequent requests or the
   ordering of messages is significant.

3.1.  Asynchronous Feature

   The "feature" attribute in the BEEP greeting contains a whitespace
   separate list of features supported by each peer.  If both lists
   contain the same feature that feature may be used by either peer.

   This document registers the feature "async".  If both peers include
   this feature in the greeting message, either peer is able to create
   an asynchronous channel.

   Figure 1 shows an example exchange where both peers declare
   willingness to use this feature.

Thomson                Expires September 24, 2009               [Page 4]
Internet-Draft         Asynchronous BEEP Channels             March 2009

      L: <wait for incoming connection>
      I: <open connection>
      L: RPY 0 0 . 0 133
      L: Content-Type: application/beep+xml
      L:
      L: <greeting features="async x-foo">
      L:    <profile uri="http://iana.org/beep/TLS" />
      L: </greeting>
      L: END
      I: RPY 0 0 . 0 69
      I: Content-Type: application/beep+xml
      I:
      I: <greeting features="async" />
      I: END

            Figure 1: BEEP greetings with asynchronous feature

   The registration template for BEEP features is included in Section 6.

3.2.  Starting an Asynchronous Channel

   To create an asynchronous channel, an "async" parameter set to "true"
   is included in the "start" request.  If omitted, or set to "false",
   the channel is not asynchronous.

   Figure 2 shows how the "async" attribute can be used to start an
   asynchronous channel.

      C: MSG 0 1 . 52 130
      C: Content-Type: application/beep+xml
      C:
      C: <start number="1" async="true">
      C:    <profile uri="http://example.org/protocol"/>
      C: </start>
      C: END
      S: RPY 0 1 . 221 102
      S: Content-Type: application/beep+xml
      S:
      S: <profile uri="http://example.org/protocol"/>
      S: END

                   Figure 2: Asynchronous Channel Start

   If the serving peer is unable to create an asynchronous channel for
   any reason, the channel start is rejected.  This could occur if the
   selected profile is not suitable for an asynchronous channel.  The
   response can include the "553" response code (parameter invalid) and
   an appropriate message, as shown in Figure 3.

Thomson                Expires September 24, 2009               [Page 5]
Internet-Draft         Asynchronous BEEP Channels             March 2009

      C: MSG 0 1 . 52 128
      C: Content-Type: application/beep+xml
      C:
      C: <start number="1" async="true">
      C:    <profile uri="http://example.org/serial"/>
      C: </start>
      C: END
      S: ERR 0 1 . 221 152
      S: Content-Type: application/beep+xml
      S:
      S: <error code="553">Profile &lt;http://example.org/serial&gt;
      S: cannot be used for asynchronous channels.</error>
      S: END

                Figure 3: Asynchronous Channel Start Error

3.3.  Asynchronous Channel Behaviour

   Asynchronous channels differ from normal BEEP channels in one way
   only: an asynchronous channel is not subject to the restrictions in
   Section 2.6.1 of [RFC3080] regarding the processing and response
   ordering.  A peer in the serving role may process and respond to
   requests in any order it chooses.

   In an asynchronous channel the "msgno" element of the frame header is
   used to correlate request and response.  A BEEP peer receiving
   responses in a different order to the requests that triggered them
   must not regard this is a protocol error.

   "MSG" messages sent on an asynchronous chanel may be processed in
   parallel by the serving peer.  Responses ("RPY", "ANS", "NUL" or
   "ERR" messages) can be sent in any order.  Different "ANS" messages
   that are sent in a one-to-many exchange may be interleaved with
   responses to other "MSG" messages.

   An asynchronous channel must still observe the rules in [RFC3080]
   regarding segmented messages.  Each message must be completed before
   any other message can be sent on that same channel.

   Note:  An exception to this rule is made in [RFC3080] for interleaved
      ANS segments sent in response to the same "MSG".  It is
      recommended that BEEP peers do not generate interleaved ANS
      segments.

   The BEEP management channel (channel 0) is never asynchronous.

Thomson                Expires September 24, 2009               [Page 6]
Internet-Draft         Asynchronous BEEP Channels             March 2009

4.  Alternatives

   The option presented in this document provides for asynchronous
   communication.  Asynchronous channels might not be applicable in
   every circumstance, particularly where ordering of requests is
   significant.  Depending on application protocol requirements, the
   alternatives discussed in this section could be more applicable.

4.1.  Increasing Throughput

   Asynchronous channels can be used to remove limitations on message
   processing throughput in some cases.  Alternatively, pipelining of
   requests can increase throughput significantly where network latency
   is the limiting factor.  Spreading requests over several channels
   increases overall throughput, if throughput is the only
   consideration.

   Note:  Be wary of false optimizations that rely on the pipelining of
      requests.  If later requests in a series of pipelined requests
      rely on state established by earlier requests, errors in earlier
      requests could invalidate later requests.

   The flow control window used in the TCP mapping [RFC3081] can
   introduce a limiting factor in throughput for individual channels.
   Choice of TCP window size similarly limits throughput, see [RFC1323].
   To avoid limitations introduced by flow control, receiving peers can
   increase the window size used; sending peers can open additional
   channels with the same profile.  Correctly managing flow control also
   applies to asynchronous channels.

4.2.  Asynchrony in the Application Protocol

   With changes to the application protocol, serial channels can be used
   for asynchronous exchanges.  Asynchrony can be provided at a protocol
   layer above BEEP by separating request and response.  This requires
   the addition of proprietary MIME headers or modifications to the
   application protocol.

   The serving peer provides an immediate "RPY" (or "NUL") response to
   requests.  This frees the channel for further requests.  The actual
   response is sent as a separate "MSG" using a special identifier
   included in the original request to correlate the response with the
   request.  This second "MSG" can be sent on the same channel (since
   these are full duplex) or on a channel specifically created for this
   purpose.

   This method is not favoured since it requires that the application
   protocol solve the problem of correlating request with response.

Thomson                Expires September 24, 2009               [Page 7]
Internet-Draft         Asynchronous BEEP Channels             March 2009

   BEEP aims to provide a general framework for the creation of an
   application protocol, and for it to not provide request/response
   correlation would limit its usefulness.  Using a MIME header is also
   possible, but using "msgno" is the most elegant solution.

5.  Security Considerations

   Enabling asynchronous messaging for a channel potentially requires
   the maintenance of additional state information.  A peer in the
   server role that does not reply to messages can cause the
   accumulation of state at the client peer.  If this state information
   were not limited, this mode could be used to perform denial of
   service.  This problem, while already present in BEEP, is potentially
   more significant due to the nature of the processing on the serving
   peer that might occur for requests received on an asynchronous
   channel.  The extent to which denial is possible is limited by what a
   serving peer accepts; the number of outstanding requests can be
   restricted to protect against excessive accumulation of state.

   Peers that serve requests on asynchronous channels are not subject to
   any specific problems from state accumulation.  Peers in the serving
   role are able to use flow control [RFC3081] to limit the consumption
   of local resources.

6.  IANA Considerations

   This section registers the BEEP "async" feature in the BEEP
   parameters registry, following the template from Section 5.2 of
   [RFC3080].

   Feature Identification:  async

   Feature Semantics:  This feature enables the creation of asynchronous
      channels, see Section 3 of RFCXXXX.  [[EDITORS NOTE: Please
      replace XXXX with the assigned number of this document.]]

   Contact Information:  Martin Thomson <martin.thomson@andrew.com>

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3080]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
              RFC 3080, March 2001.

Thomson                Expires September 24, 2009               [Page 8]
Internet-Draft         Asynchronous BEEP Channels             March 2009

7.2.  Informative References

   [RFC3081]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
              March 2001.

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

Author's Address

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   EMail: martin.thomson@andrew.com
   URI:   http://www.andrew.com/

Thomson                Expires September 24, 2009               [Page 9]