idnits 2.17.1 draft-montenegro-httpbis-http2-fc-principles-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 8, 2012) is 4154 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) == Unused Reference: 'RFC2119' is defined on line 153, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p1-messaging' is defined on line 160, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p2-semantics' is defined on line 166, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'I-D.montenegro-httpbis-speed-mobility' is defined on line 185, but no explicit reference was found in the text == Unused Reference: 'I-D.tarreau-httpbis-network-friendly' is defined on line 191, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-21 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-21 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Mazahir 3 Internet-Draft J. Padhye 4 Expires: June 11, 2013 Microsoft 5 W. Chan 6 R. Peon 7 Google 8 R. Trace 9 Microsoft 10 S. Loreto 11 Ericsson 12 G. Montenegro 13 Microsoft 14 December 8, 2012 16 HTTP 2.0 Principles for Flow Control 17 draft-montenegro-httpbis-http2-fc-principles-01 19 Abstract 21 This document states the principles for flow control in HTTP 2.0. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 11, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Principles for Flow Control in HTTP 2.0 Multiplexing . . . . . 4 59 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 4.2. Informative References . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 HTTP/2.0 introduces multiplexed streams over a given TCP connection. 68 In HTTP 1.X, there is no interleaving of Request/Response pairs. 69 Thus, any flow control issues are mostly left to the underlying TCP 70 implementation. In HTTP 2.0, each Request/Response pair uses a 71 separate stream, sharing the same TCP connection with other such 72 pairs over different streams. All such streams will be vying for a 73 common underlying resource of a single TCP connection. Given that 74 this interaction among all the streams is not visible to the TCP 75 implementation, handling the interaction among them has to be solved 76 at the HTTP 2.0 multiplexing layer. There are issues of 77 prioritization, head-of-line blocking and flow control. Perhaps the 78 most complex aspect is that of flow control. It may be that flow 79 control for HTTP 2.0 multiplexing will follow a path similar to what 80 TCP's complex dynamics have followed throughout the years. In 81 particular, TCP congestion control has seen a constant progress of 82 improved specifications based on measurements and research of the 83 networking community. What the TCP community recognized early on was 84 that this was a hard problem. Thus, the best course of action was to 85 agree on a minimal set of rules or principles (e.g., TCP 86 "friendliness"). Many TCP congestion control algorithms are then 87 possible as a (mostly) local implementation issue giving rise to TCP 88 Reno, Tahoe, Vegas, CTCP, and many more. 90 Flow control for HTTP 2.0 multiplexing over TCP is also a complex 91 issue. This document proposes (1) a set of principles aimed at 92 preventing egregious behavior, while allowing for future and ongoing 93 improvement of flow control algorithms, and (2) a simple flow control 94 algorithm that could be implemented in the absence of better schemes 95 (TBD). Other flow control algorithms with subsequent improvements 96 should be specified in separate documents without encumbering nor 97 delaying the base HTTP 2.0 specification. This is similar to how the 98 myriad TCP congestion algorithms published so far have been specified 99 separately from the base TCP documents. 101 The goal of this document is to propose additional text to the 102 HTTP/2.0 specification. The starting point for HTTP/2.0, the SPDY 103 [I-D.mbelshe-httpbis-spdy] protocol, does not have much language with 104 respect to flow control. Hence, the text below is offered as a new 105 section or sections within the HTTP/2.0 document. 107 2. Principles for Flow Control in HTTP 2.0 Multiplexing 109 Flow control for Multiplexing in HTTP 2.0 must follow these 110 principles: 112 1. Flow control is hop by hop (where "hop" means an HTTP 2.0 hop), 113 and not end-to-end. 115 2. Flow control is based on window update messages. It is 116 essentially a credit-based scheme. 118 3. Flow control is directional and is determined by the receiver. 119 Flow control MAY be declared by the receiver and MUST be heeded 120 by the sender. For example, a client, a server or a proxy (in 121 their role as a "receiver") independently advertise their flow 122 control preference. The other side when operating as a "sender" 123 must heed that preference. 125 4. Flow control in the direction towards the receiver can be OFF or 126 ON as determined by the receiver. It is OFF if no flow control 127 is advertised by the receiver, or if the receiver declares 128 "infinite" credit to the sender. 130 5. HTTP 2.0 should only standardize the format of the window update 131 message and its semantics. In particular, the algorithms used by 132 the receiver to decide when to send window update messages, and 133 how much to update the window by, are not mandated in the spec. 134 The draft should, however, provide some illustrative examples. 136 NOTE: Whether flow control operates on a per-stream basis, on a per- 137 session (per-TCP connection) basis or on both a per-stream and a per- 138 session basis is TBD. 140 The spec will not define the algorithms the sender will use to manage 141 priorities among streams and to minimize head of the line blocking. 142 This is included for completeness, but is essentially independent of 143 flow-control. 145 3. Acknowledgements 147 This document was produced using the xml2rfc tool [RFC2629]. 149 4. References 151 4.1. Normative References 153 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 154 Requirement Levels", BCP 14, RFC 2119, March 1997. 156 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 157 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 158 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 160 [I-D.ietf-httpbis-p1-messaging] 161 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 162 (HTTP/1.1): Message Syntax and Routing", 163 draft-ietf-httpbis-p1-messaging-21 (work in progress), 164 October 2012. 166 [I-D.ietf-httpbis-p2-semantics] 167 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 168 (HTTP/1.1): Semantics and Content", 169 draft-ietf-httpbis-p2-semantics-21 (work in progress), 170 October 2012. 172 4.2. Informative References 174 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 175 June 1999. 177 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 178 RFC 6455, December 2011. 180 [I-D.mbelshe-httpbis-spdy] 181 Belshe, M. and R. Peon, "SPDY Protocol", 182 draft-mbelshe-httpbis-spdy-00 (work in progress), 183 February 2012. 185 [I-D.montenegro-httpbis-speed-mobility] 186 Trace, R., Foresti, A., Singhal, S., Mazahir, O., Nielsen, 187 H., Raymor, B., Rao, R., and G. Montenegro, "HTTP Speed+ 188 Mobility", draft-montenegro-httpbis-speed-mobility-02 189 (work in progress), June 2012. 191 [I-D.tarreau-httpbis-network-friendly] 192 Tarreau, W., Jeffries, A., and A. Croy, "Proposal for a 193 Network-Friendly HTTP Upgrade", 194 draft-tarreau-httpbis-network-friendly-00 (work in 195 progress), March 2012. 197 Authors' Addresses 199 Osama Mazahir 200 Microsoft 202 Email: OsamaM@microsoft.com 204 Jitu Padhye 205 Microsoft 207 Email: padhye@microsoft.com 209 William Chan 210 Google 212 Email: willchan@chromium.org 214 Roberto Peon 215 Google 217 Email: fenix@google.com 219 Rob Trace 220 Microsoft 222 Email: Rob.Trace@microsoft.com 224 Salvatore Loreto 225 Ericsson 227 Email: salvatore.loreto@ericsson.com 229 Gabriel Montenegro 230 Microsoft 232 Email: Gabriel.Montenegro@microsoft.com