WDIFF

draft-thomson-beep-async-02.txt --> rfc5573.txt

Network Working Group M. Thomson
Internet-Draft
Request for Comments: 5573 Andrew
Intended status: Standards Track March 23, 2009
Expires: September 24,
Category: Experimental June 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 memo defines an Experimental Protocol for the Internet Engineering
Task Force (IETF), its areas,
community. It does not specify an Internet standard of any kind.
Discussion and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid suggestions for a maximum improvement are requested.
Distribution of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It this memo 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. unlimited.

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 a 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
2. Conventions used in this document . . . . . . . . . . . . . . . 4
3. Asynchronous BEEP Channels . . . . . . . . . . . . . . . . . . 4
3.1. ......................................3
2.1. Asynchronous Feature . . . . . . . . . . . . . . . . . . . 4
3.2. .......................................3
2.2. Starting an Asynchronous Channel . . . . . . . . . . . . . 5
3.3. ...........................4
2.3. Asynchronous Channel Behaviour . . . . . . . . . . . . . . 6
4. Behavior ..............................5
2.4. Error Handling .............................................6
3. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. ....................................................6
3.1. Increasing Throughput . . . . . . . . . . . . . . . . . . . 7
4.2. ......................................6
3.2. Asynchrony in the Application Protocol . . . . . . . . . . 7
5. .....................7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. .........................................7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. .............................................8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. ......................................................8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. .......................................8
6.2. Informative References . . . . . . . . . . . . . . . . . . 9 .....................................8

Thomson Expires September 24, 2009 Experimental [Page 2]

Internet-Draft 1]

RFC 5573 Asynchronous BEEP Channels March June 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 authentication, and
asynchrony. However 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 behavior 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 a 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
except that 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.

Thomson Experimental [Page 2]

RFC 5573 Asynchronous BEEP Channels June 2009

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

This document are to be interpreted is published as described an Experimental RFC in [RFC2119]. Similar order to find
out whether the extension is going to be deployed for use in [RFC3080], these words are written in lower case; this document
refrains from unnecessary shouting.

3. a
variety of use cases and applications.

2. 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 a 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.

2.1. Asynchronous Feature

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

This document registers the feature "async". If both peers either peer does not
include this feature in the greeting message, either neither 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 Experimental [Page 4]

Internet-Draft 3]

RFC 5573 Asynchronous BEEP Channels March June 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" uri="http://example.com/beep/APP" />
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 Greetings with asynchronous feature Asynchronous Feature

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

3.2. 5.

2.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 Experimental [Page 5]

Internet-Draft 4]

RFC 5573 Asynchronous BEEP Channels March June 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.

2.3. Asynchronous Channel Behaviour Behavior

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 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 than the requests that triggered them
must not regard this is as a protocol error.

"MSG" messages sent on an asynchronous chanel channel may be processed in
parallel by the serving peer. Responses ("RPY", "ANS", "NUL" "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
"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 Experimental [Page 6]

Internet-Draft 5]

RFC 5573 Asynchronous BEEP Channels March June 2009

2.4. Error Handling

BEEP does not provide any mechanism for managing a peer that does not
respond to a request. Synchronous channels cannot be used or even
closed if a peer does not provide a response to a request. The only
remedy available is closing the underlying transport. While an
asynchronous channel cannot be closed, it can still be used for
further requests. However, any outstanding request still consumes
state resources. Client peers may dispose of such state after a
configured interval, but must be prepared to discard unrecognized
responses if they do so.

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

3.1. Increasing Throughput

Asynchronous

In some cases, asynchronous channels can be used to remove
limitations on message processing throughput in some cases. throughput. 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.

Thomson Experimental [Page 6]

RFC 5573 Asynchronous BEEP Channels June 2009

3.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 favored 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.

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

A client peer maintains state for each request that it sends. A
client peer should enforce a configurable limit on the number of
requests that it will allow to be outstanding at any time. This
limit could be enforced at channel, connection, or application scope.
Once this limit is reached, the client peer might prevent or block
further requests from been generated.

Peers that serve requests on asynchronous channels are not subject to
any specific problems from also accumulate
state accumulation. when a request is accepted for processing. Peers in the
serving role are able may similarly limit to use the number of requests that are
processed concurrently. Once this limit is reached the receiving

Thomson Experimental [Page 7]

RFC 5573 Asynchronous BEEP Channels June 2009

peer can either stop reading new requests, or might start rejecting
such requests by generating error responses. Alternatively, the flow
control [RFC3081] can be used; "SEQ" frames can be suppressed,
allowing the flow control window to limit close and preventing the consumption receipt
of local resources.

6. further requests.

5. 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 2 of this document.]] RFC 5573.

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

6. References

7.1.

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

6.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 Experimental [Page 9] 8]

----