idnits 2.17.1 draft-montenegro-httpbis-http2-fc-principles-00.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 (November 14, 2012) is 4181 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 145, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 148, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p1-messaging' is defined on line 152, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p2-semantics' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RFC6455' is defined on line 169, but no explicit reference was found in the text == Unused Reference: 'I-D.montenegro-httpbis-speed-mobility' is defined on line 177, but no explicit reference was found in the text == Unused Reference: 'I-D.tarreau-httpbis-network-friendly' is defined on line 183, 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: May 18, 2013 R. Trace 5 Microsoft 6 S. Loreto 7 Ericsson 8 G. Montenegro 9 Microsoft 10 November 14, 2012 12 HTTP 2.0 Principles for Flow Control 13 draft-montenegro-httpbis-http2-fc-principles-00 15 Abstract 17 This document states the principles for flow control in HTTP 2.0. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 18, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Principles for Flow Control in HTTP 2.0 Multiplexing . . . . . 4 55 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 4.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 HTTP/2.0 introduces multiplexed streams over a given TCP connection. 64 In HTTP 1.X, there is no interleaving of Request/Response pairs. 65 Thus, any flow control issues are mostly left to the underlying TCP 66 implementation. In HTTP 2.0, each Request/Response pair uses a 67 separate stream, sharing the same TCP connection with other such 68 pairs over different streams. All such streams will be vying for a 69 common underlying resource of a single TCP connection. Given that 70 this interaction among all the streams is not visible to the TCP 71 implementation, handling the interaction among them has to be solved 72 at the HTTP 2.0 multiplexing layer. There are issues of 73 prioritization, head-of-line blocking and flow control. Perhaps the 74 most complex aspect is that of flow control. It seems likely that 75 flow control will follow a path similar to what TCP's complex 76 dynamics have followed throughout the years. In particular, TCP 77 congestion control has seen a constant progress of improved 78 specifications based on measurements and research of the networking 79 community. What the TCP community recognized early on was that this 80 was a hard problem. Thus, the best course of action was to agree on 81 a minimal set of rules or principles (e.g., TCP "friendliness"). 82 Many TCP algorithms are then possible as a (mostly) local 83 implementation issue giving rise to TCP Reno, Tahoe, Vegas, CTCP, and 84 many more. 86 Flow control for HTTP 2.0 multiplexing over TCP is also a complex 87 issue. This document proposes (1) a set of principles aimed at 88 preventing egregious behavior, while allowing for future and ongoing 89 improvement of flow control algorithms, and (2) a simple flow control 90 algorithm that could be implemented in the absence of better schemes 91 (TBD). Other flow control algorithms with subsequent improvements 92 should be specified in separate documents without encumbering nor 93 delaying the base HTTP 2.0 specification. This is similar to how the 94 myriad TCP congestion algorithms published so far have been specified 95 separately from the base TCP documents. 97 The goal of this document is to propose additional text to the 98 HTTP/2.0 specification. The starting point for HTTP/2.0, the SPDY 99 [I-D.mbelshe-httpbis-spdy] protocol, does not have much language with 100 respect to flow control. Hence, the text below is offered as a new 101 section or sections within the HTTP/2.0 document. 103 2. Principles for Flow Control in HTTP 2.0 Multiplexing 105 Flow control for Multiplexing in HTTP 2.0 must follow these 106 principles: 108 1. Flow control is hop by hop (where "hop" means an HTTP 2.0 hop), 109 and not end-to-end. 111 2. Flow control is based on window update messages. It is 112 essentially a credit-based scheme. 114 3. Flow control is directional. The client and server independently 115 advertise their flow control preference. It MAY be declared by 116 the receiver and MUST be heeded by the sender. 118 4. Flow control can be OFF or ON. It is OFF if no flow control is 119 advertised by a receiver, or if it declares "infinite" credit to 120 the sender. 122 5. HTTP 2.0 should only standardize the format of the window update 123 message and its semantics. In particular, the algorithms used by 124 the receiver to decide when to send window update messages, and 125 how much to update the window by, are not mandated in the spec. 126 The draft should, however, provide some illustrative examples. 128 NOTE: Whether flow control operates on a per-stream basis, on a per- 129 session (per-TCP connection) basis or on both a per-stream and a per- 130 session basis is TBD. 132 The spec will not define the algorithms the sender will use to manage 133 priorities among streams and to minimize head of the line blocking. 134 This is included for completeness, but is essentially independent of 135 flow-control. 137 3. Acknowledgements 139 This document was produced using the xml2rfc tool [RFC2629]. 141 4. References 143 4.1. Normative References 145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 146 Requirement Levels", BCP 14, RFC 2119, March 1997. 148 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 149 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 150 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 152 [I-D.ietf-httpbis-p1-messaging] 153 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 154 (HTTP/1.1): Message Syntax and Routing", 155 draft-ietf-httpbis-p1-messaging-21 (work in progress), 156 October 2012. 158 [I-D.ietf-httpbis-p2-semantics] 159 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 160 (HTTP/1.1): Semantics and Content", 161 draft-ietf-httpbis-p2-semantics-21 (work in progress), 162 October 2012. 164 4.2. Informative References 166 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 167 June 1999. 169 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 170 RFC 6455, December 2011. 172 [I-D.mbelshe-httpbis-spdy] 173 Belshe, M. and R. Peon, "SPDY Protocol", 174 draft-mbelshe-httpbis-spdy-00 (work in progress), 175 February 2012. 177 [I-D.montenegro-httpbis-speed-mobility] 178 Trace, R., Foresti, A., Singhal, S., Mazahir, O., Nielsen, 179 H., Raymor, B., Rao, R., and G. Montenegro, "HTTP Speed+ 180 Mobility", draft-montenegro-httpbis-speed-mobility-02 181 (work in progress), June 2012. 183 [I-D.tarreau-httpbis-network-friendly] 184 Tarreau, W., Jeffries, A., and A. Croy, "Proposal for a 185 Network-Friendly HTTP Upgrade", 186 draft-tarreau-httpbis-network-friendly-00 (work in 187 progress), March 2012. 189 Authors' Addresses 191 Osama Mazahir 192 Microsoft 194 Email: OsamaM@microsoft.com 196 Jitu Padhye 197 Microsoft 199 Email: padhye@microsoft.com 201 Rob Trace 202 Microsoft 204 Email: Rob.Trace@microsoft.com 206 Salvatore Loreto 207 Ericsson 209 Email: salvatore.loreto@ericsson.com 211 Gabriel Montenegro 212 Microsoft 214 Email: Gabriel.Montenegro@microsoft.com