idnits 2.17.1 draft-thomson-beep-async-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2009) is 5484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Andrew 4 Intended status: Standards Track March 23, 2009 5 Expires: September 24, 2009 7 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) 8 draft-thomson-beep-async-02 10 Status of This Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 24, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Blocks Extensible Exchange Protocol (BEEP) provides a protocol 47 framework for the development of application protocols. This 48 document describes an BEEP feature that enables asynchrony for 49 individual channels. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Conventions used in this document . . . . . . . . . . . . . . . 4 55 3. Asynchronous BEEP Channels . . . . . . . . . . . . . . . . . . 4 56 3.1. Asynchronous Feature . . . . . . . . . . . . . . . . . . . 4 57 3.2. Starting an Asynchronous Channel . . . . . . . . . . . . . 5 58 3.3. Asynchronous Channel Behaviour . . . . . . . . . . . . . . 6 59 4. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Increasing Throughput . . . . . . . . . . . . . . . . . . . 7 61 4.2. Asynchrony in the Application Protocol . . . . . . . . . . 7 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Blocks Extensible Exchange Protocol (BEEP) provides a protocol 71 framework that manages many of the aspects necessary in developing an 72 application protocol: framing, encoding, privacy, authentication and 73 asynchrony. However the asynchrony provided by BEEP is limited to 74 asynchrony between channels; replies to messages sent on any channel 75 are strictly ordered. 77 Serial processing behaviour is desirable for a range of applications. 78 However, serial processing is less suitable for applications that 79 rely more heavily on asynchrony. In particular, if a response takes 80 a significant amount of time to create, the channel is effectively 81 blocked until the request has been processed and the response sent. 82 Pipelining only ensures that network latency does not add to this 83 time; subsequent requests cannot be processed until a response is 84 made to the first request. 86 Asynchronous applications require a protocol that is able to support 87 a large number of concurrent outstanding requests. The analogy of a 88 channel as a thread does not scale to the large number of threads 89 used in modern systems. Modern applications regularly have large 90 numbers of concurrent processing threads. Thus, a better way of 91 multiplexing large numbers of concurrent requests is required. 93 This document describes an BEEP feature, an extension to BEEP, that 94 enables the creation of an asynchronous channel. An asynchronous 95 channel is a channel where response ordering is not fixed to the 96 order of the requests sent by the client peer. An asynchronous 97 channel is identical to other channels, using unmodified framing; 98 only requests may be processed in parallel and responses may be sent 99 in any order. 101 An asynchronous channel enables the efficient use of a single channel 102 for multiple concurrent requests. There is no impact on requests 103 arising from the timing of responses to other requests. The 104 requesting peer can process responses to the requests it sends as 105 they come available; similarly, the serving peer can take advantage 106 of parallel processing without artificial constraints on the order of 107 responses. 109 Asynchronous channels allow for greater throughput where the serving 110 peer requires any time to process requests. This is particularly 111 relevant where the serving peer needs to perform lengthy computations 112 or make network-based requests as a part of servicing the request. 114 BEEP feature negotiation is used to ensure that both peers are 115 mutually willing to create asynchronous channels. A means for 116 establishing an asynchronous channel is described. 118 2. Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. Similar to 123 in [RFC3080], these words are written in lower case; this document 124 refrains from unnecessary shouting. 126 3. Asynchronous BEEP Channels 128 This document defines a BEEP feature that enables the use of 129 asynchronous channels. An asynchronous channel is a BEEP channel 130 that is not subject to the restrictions of Section 2.6.1 of [RFC3080] 131 regarding ordering of responses; requests can be processed and 132 responded to in any order by the serving peer. 134 Asynchronous channels use the "msgno" element of the BEEP frame 135 header to correlate request and response. Regular BEEP channels do 136 not use "msgno" for request/response correlation, contrary to what 137 might be inferred by the presence of the parameter. In a regular 138 BEEP channel, the "msgno" only serves as an means of checking for 139 protocol errors. 141 Asynchronous channels are not suitable for applications where state 142 established by requests is relied upon in subsequent requests or the 143 ordering of messages is significant. 145 3.1. Asynchronous Feature 147 The "feature" attribute in the BEEP greeting contains a whitespace 148 separate list of features supported by each peer. If both lists 149 contain the same feature that feature may be used by either peer. 151 This document registers the feature "async". If both peers include 152 this feature in the greeting message, either peer is able to create 153 an asynchronous channel. 155 Figure 1 shows an example exchange where both peers declare 156 willingness to use this feature. 158 L: 159 I: 160 L: RPY 0 0 . 0 133 161 L: Content-Type: application/beep+xml 162 L: 163 L: 164 L: 165 L: 166 L: END 167 I: RPY 0 0 . 0 69 168 I: Content-Type: application/beep+xml 169 I: 170 I: 171 I: END 173 Figure 1: BEEP greetings with asynchronous feature 175 The registration template for BEEP features is included in Section 6. 177 3.2. Starting an Asynchronous Channel 179 To create an asynchronous channel, an "async" parameter set to "true" 180 is included in the "start" request. If omitted, or set to "false", 181 the channel is not asynchronous. 183 Figure 2 shows how the "async" attribute can be used to start an 184 asynchronous channel. 186 C: MSG 0 1 . 52 130 187 C: Content-Type: application/beep+xml 188 C: 189 C: 190 C: 191 C: 192 C: END 193 S: RPY 0 1 . 221 102 194 S: Content-Type: application/beep+xml 195 S: 196 S: 197 S: END 199 Figure 2: Asynchronous Channel Start 201 If the serving peer is unable to create an asynchronous channel for 202 any reason, the channel start is rejected. This could occur if the 203 selected profile is not suitable for an asynchronous channel. The 204 response can include the "553" response code (parameter invalid) and 205 an appropriate message, as shown in Figure 3. 207 C: MSG 0 1 . 52 128 208 C: Content-Type: application/beep+xml 209 C: 210 C: 211 C: 212 C: 213 C: END 214 S: ERR 0 1 . 221 152 215 S: Content-Type: application/beep+xml 216 S: 217 S: Profile <http://example.org/serial> 218 S: cannot be used for asynchronous channels. 219 S: END 221 Figure 3: Asynchronous Channel Start Error 223 3.3. Asynchronous Channel Behaviour 225 Asynchronous channels differ from normal BEEP channels in one way 226 only: an asynchronous channel is not subject to the restrictions in 227 Section 2.6.1 of [RFC3080] regarding the processing and response 228 ordering. A peer in the serving role may process and respond to 229 requests in any order it chooses. 231 In an asynchronous channel the "msgno" element of the frame header is 232 used to correlate request and response. A BEEP peer receiving 233 responses in a different order to the requests that triggered them 234 must not regard this is a protocol error. 236 "MSG" messages sent on an asynchronous chanel may be processed in 237 parallel by the serving peer. Responses ("RPY", "ANS", "NUL" or 238 "ERR" messages) can be sent in any order. Different "ANS" messages 239 that are sent in a one-to-many exchange may be interleaved with 240 responses to other "MSG" messages. 242 An asynchronous channel must still observe the rules in [RFC3080] 243 regarding segmented messages. Each message must be completed before 244 any other message can be sent on that same channel. 246 Note: An exception to this rule is made in [RFC3080] for interleaved 247 ANS segments sent in response to the same "MSG". It is 248 recommended that BEEP peers do not generate interleaved ANS 249 segments. 251 The BEEP management channel (channel 0) is never asynchronous. 253 4. Alternatives 255 The option presented in this document provides for asynchronous 256 communication. Asynchronous channels might not be applicable in 257 every circumstance, particularly where ordering of requests is 258 significant. Depending on application protocol requirements, the 259 alternatives discussed in this section could be more applicable. 261 4.1. Increasing Throughput 263 Asynchronous channels can be used to remove limitations on message 264 processing throughput in some cases. Alternatively, pipelining of 265 requests can increase throughput significantly where network latency 266 is the limiting factor. Spreading requests over several channels 267 increases overall throughput, if throughput is the only 268 consideration. 270 Note: Be wary of false optimizations that rely on the pipelining of 271 requests. If later requests in a series of pipelined requests 272 rely on state established by earlier requests, errors in earlier 273 requests could invalidate later requests. 275 The flow control window used in the TCP mapping [RFC3081] can 276 introduce a limiting factor in throughput for individual channels. 277 Choice of TCP window size similarly limits throughput, see [RFC1323]. 278 To avoid limitations introduced by flow control, receiving peers can 279 increase the window size used; sending peers can open additional 280 channels with the same profile. Correctly managing flow control also 281 applies to asynchronous channels. 283 4.2. Asynchrony in the Application Protocol 285 With changes to the application protocol, serial channels can be used 286 for asynchronous exchanges. Asynchrony can be provided at a protocol 287 layer above BEEP by separating request and response. This requires 288 the addition of proprietary MIME headers or modifications to the 289 application protocol. 291 The serving peer provides an immediate "RPY" (or "NUL") response to 292 requests. This frees the channel for further requests. The actual 293 response is sent as a separate "MSG" using a special identifier 294 included in the original request to correlate the response with the 295 request. This second "MSG" can be sent on the same channel (since 296 these are full duplex) or on a channel specifically created for this 297 purpose. 299 This method is not favoured since it requires that the application 300 protocol solve the problem of correlating request with response. 302 BEEP aims to provide a general framework for the creation of an 303 application protocol, and for it to not provide request/response 304 correlation would limit its usefulness. Using a MIME header is also 305 possible, but using "msgno" is the most elegant solution. 307 5. Security Considerations 309 Enabling asynchronous messaging for a channel potentially requires 310 the maintenance of additional state information. A peer in the 311 server role that does not reply to messages can cause the 312 accumulation of state at the client peer. If this state information 313 were not limited, this mode could be used to perform denial of 314 service. This problem, while already present in BEEP, is potentially 315 more significant due to the nature of the processing on the serving 316 peer that might occur for requests received on an asynchronous 317 channel. The extent to which denial is possible is limited by what a 318 serving peer accepts; the number of outstanding requests can be 319 restricted to protect against excessive accumulation of state. 321 Peers that serve requests on asynchronous channels are not subject to 322 any specific problems from state accumulation. Peers in the serving 323 role are able to use flow control [RFC3081] to limit the consumption 324 of local resources. 326 6. IANA Considerations 328 This section registers the BEEP "async" feature in the BEEP 329 parameters registry, following the template from Section 5.2 of 330 [RFC3080]. 332 Feature Identification: async 334 Feature Semantics: This feature enables the creation of asynchronous 335 channels, see Section 3 of RFCXXXX. [[EDITORS NOTE: Please 336 replace XXXX with the assigned number of this document.]] 338 Contact Information: Martin Thomson 340 7. References 342 7.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 348 RFC 3080, March 2001. 350 7.2. Informative References 352 [RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 353 March 2001. 355 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 356 for High Performance", RFC 1323, May 1992. 358 Author's Address 360 Martin Thomson 361 Andrew 362 PO Box U40 363 Wollongong University Campus, NSW 2500 364 AU 366 Phone: +61 2 4221 2915 367 EMail: martin.thomson@andrew.com 368 URI: http://www.andrew.com/