Network Working Group M. Thomson
Internet-Draft Andrew
Intended status: Standards Track May 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.
Thomson Expires November 28, 2008 [Page 1]
Internet-Draft Asynchronous BEEP Channels May 2008
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 November 28, 2008 [Page 2]
Internet-Draft Asynchronous BEEP Channels May 2008
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 November 28, 2008 [Page 3]
Internet-Draft Asynchronous BEEP Channels May 2008
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]. However,
these words are written in lower case; this document refrains from
unnecessary shouting (BEEP being a necessary exception).
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 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.
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 in an example where both peers declare willingness to
use this feature.
Thomson Expires November 28, 2008 [Page 4]
Internet-Draft Asynchronous BEEP Channels May 2008
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 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
Thomson Expires November 28, 2008 [Page 5]
Internet-Draft Asynchronous BEEP Channels May 2008
shown in Figure 3.
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 <http://example.org/protocol>
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.
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]
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 November 28, 2008 [Page 6]
Internet-Draft Asynchronous BEEP Channels May 2008
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.
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 [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, increase the window
size used or open more channels. This method 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 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
Thomson Expires November 28, 2008 [Page 7]
Internet-Draft Asynchronous BEEP Channels May 2008
would have also been 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 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 [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 (this document). [[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 November 28, 2008 [Page 8]
Internet-Draft Asynchronous BEEP Channels May 2008
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 November 28, 2008 [Page 9]
Internet-Draft Asynchronous BEEP Channels May 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Thomson Expires November 28, 2008 [Page 10]