TOC 
Network Working GroupM. Thomson
Internet-DraftAndrew
Intended status: Standards TrackMay 27, 2008
Expires: November 28, 2008 


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

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 November 28, 2008.

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 individual channels.



Table of Contents

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




 TOC 

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 establishing an asynchronous channel is described.



 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). However, these words are written in lower case; this document refrains from unnecessary shouting (BEEP being a necessary exception).



 TOC 

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] (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.) regarding ordering of responses; requests can be processed and responded to in any order by the serving peer.

Asynchronous channels use the existing 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. In a regular BEEP channel, the msgno only serves as an means of checking for protocol errors. Asynchronous channels, as described in this document, use msgno for request/response correlation.

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



 TOC 

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 (BEEP greetings with asynchronous feature) shows in an example where both peers declare willingness to use this feature.



   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 (IANA Considerations).



 TOC 

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 (Asynchronous Channel Start) 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 for any reason the serving peer is unable to create an asynchronous channel for the given profile, 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 (Asynchronous Channel Start Error).



   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/protocol&gt;
   S: cannot be used for asynchronous channels.</error>
   S: END
 Figure 3: Asynchronous Channel Start Error 



 TOC 

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] (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.) regarding the processing and response ordering. A peer in the serving role may process and respond to requests in any order it chooses.

On asynchronous channels 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 triggerred 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] (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.) 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] (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.) 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.



 TOC 

4.  Alternatives

The option presented in this document provides for asynchronous communication with no negative impact on throughput. Depending on application protocol requirements, the alternatives discussed in this section could be useful.



 TOC 

4.1.  Increasing Throughput

Asynchronous channels are not necessary for every application. Asynchronous channels are unnecessary if message processing throughput is the primary concern. 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 (Rose, M., “Mapping the BEEP Core onto TCP,” March 2001.) [RFC3081] can introduce a limiting factor in throughput for individual channels. Choice of TCP window size similarly limits throughput, see [RFC1323] (Jacobson, V., Braden, B., and D. Borman, “TCP Extensions for High Performance,” May 1992.). To avoid limitations introduced by flow control, increase the window size used or open more channels. This method also applies to asynchronous channels.



 TOC 

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 two. 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. 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. Standardizing a MIME header would have also been possible, but using msgno is the most elegant solution.



 TOC 

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 implied nature of the processing that occurs on the serving peer. However, any denial of service is largely as a result of local processing; limits to the number of outstanding requests protects 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 (Rose, M., “Mapping the BEEP Core onto TCP,” March 2001.) [RFC3081] to limit the consumption of local resources.



 TOC 

6.  IANA Considerations

This section registers the BEEP async feature in the BEEP parameters registry, following the template from Section 5.2 of [RFC3080] (Rose, M., “The Blocks Extensible Exchange Protocol Core,” March 2001.).

Feature Identification:
async
Feature Semantics:
This feature enables the creation of asynchronous channels, see Section 3 (Asynchronous BEEP Channels) of RFCXXXX (this document). [[EDITORS NOTE: Please replace XXXX with the assigned number of this document.]]
Contact Information:
Martin Thomson <martin.thomson@andrew.com>



 TOC 

7.  References



 TOC 

7.1. Normative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3080] Rose, M., “The Blocks Extensible Exchange Protocol Core,” RFC 3080, March 2001 (TXT, HTML, XML).


 TOC 

7.2. Informative References

[RFC3081] Rose, M., “Mapping the BEEP Core onto TCP,” RFC 3081, March 2001 (TXT, HTML, XML).
[RFC1323] Jacobson, V., Braden, B., and D. Borman, “TCP Extensions for High Performance,” RFC 1323, May 1992 (TXT).


 TOC 

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/


 TOC 

Full Copyright Statement

Intellectual Property