One document matched: draft-montenegro-httpbis-http2-fc-principles-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC0793 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
  <!ENTITY RFC1738 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1738.xml'>
  <!ENTITY RFC1950 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1950.xml'>
  <!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY RFC2285 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2285.xml'>
  <!ENTITY RFC2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
  <!ENTITY RFC2617 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
  <!ENTITY RFC2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
  <!ENTITY RFC2818 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
  <!ENTITY RFC4366 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml'>
  <!ENTITY RFC4559 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml'>
  <!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
  <!ENTITY RFC6454 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml'>
  <!ENTITY RFC6455 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml'>
]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xml"?>

<?rfc toc="yes" symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-montenegro-httpbis-http2-fc-principles-00">
  <front>
	  <title abbrev="Principles for Flow Control in HTTP 2.0">HTTP 2.0 Principles for Flow Control</title>

    <author initials="O." surname="Mazahir" fullname="Osama Mazahir">
      <organization>Microsoft</organization>
      <address>
        <email>OsamaM@microsoft.com</email>
      </address>
    </author>

    <author initials="J." surname="Padhye" fullname="Jitu Padhye">
      <organization>Microsoft</organization>
      <address>
        <email>padhye@microsoft.com</email>
      </address>
    </author>

    <author initials="R." surname="Trace" fullname="Rob Trace">
      <organization>Microsoft</organization>
      <address>
        <email>Rob.Trace@microsoft.com</email>
      </address>
    </author>

     <author initials="S." surname="Loreto" fullname="Salvatore Loreto">
      <organization>Ericsson</organization>
      <address>
        <email>salvatore.loreto@ericsson.com</email>
      </address>
    </author>

    <author initials="G." surname="Montenegro" fullname="Gabriel Montenegro">
      <organization>Microsoft</organization>
      <address>
        <email>Gabriel.Montenegro@microsoft.com</email>
      </address>
    </author>

    <date month="November" year="2012" />
    <area>Applications</area>
    <keyword>HTTP</keyword>
    <abstract>
	    <t>
This document states the principles for flow control in HTTP 2.0. 
	    </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
	<t>

		HTTP/2.0 introduces multiplexed streams over a given TCP connection. In HTTP 1.X,
		there is no interleaving of Request/Response pairs. Thus, any flow control issues
		are mostly left to the underlying TCP implementation. In HTTP 2.0, each Request/Response
		pair uses a separate stream, sharing the same TCP connection with other such pairs over different 
		streams. All such streams will be vying for a common underlying resource of a single TCP 
		connection. Given that this interaction among all the streams is not visible to the
		TCP implementation, handling the interaction among them has to be solved at the HTTP 2.0
		multiplexing layer. There are issues of prioritization, head-of-line blocking and flow control.
		Perhaps the most complex aspect is that of flow control. It seems likely that flow control will
		follow a path similar to what TCP's complex dynamics have followed throughout the years.
		In particular, TCP congestion control has seen a constant progress of improved specifications
		based on measurements and research of the networking community. What the TCP community recognized early
		on was that this was a hard problem. Thus, the best course of action was to agree on a minimal
		set of rules or principles (e.g., TCP "friendliness"). Many TCP algorithms are then possible
		as a (mostly) local implementation issue giving rise to TCP Reno, Tahoe, Vegas, CTCP, and many
		more.
	</t>
	<t>
		Flow control for HTTP 2.0 multiplexing over TCP is also a complex issue. This document proposes (1) a set of
		principles aimed at preventing egregious behavior, while allowing for future and ongoing improvement 
		of flow control algorithms, and (2) a simple flow control algorithm that could be implemented in the
		absence of better schemes (TBD). Other flow control algorithms with subsequent improvements should be 
		specified in separate documents without encumbering
		nor delaying the base HTTP 2.0 specification. This is similar to how the myriad TCP congestion algorithms
		published so far have been specified separately from the base TCP documents.
	</t>
	<t>
		The goal of this document is to propose additional text to the HTTP/2.0 specification.
		The starting point for HTTP/2.0, the SPDY <xref target='I-D.mbelshe-httpbis-spdy'/>
		protocol, does not have much language with respect to flow control. Hence, the 
		text below is offered as a new section or sections within the HTTP/2.0
		document.
	</t>
	</section>


<section title="Principles for Flow Control in HTTP 2.0 Multiplexing"> <t>
		Flow control for Multiplexing in HTTP 2.0 must follow these principles:
        <list style='numbers'>
		<t> 
			Flow control is hop by hop (where "hop" means an HTTP 2.0 hop), and not end-to-end. 
		</t>
		<t> 
			Flow control is based on window update messages. It is essentially a credit-based scheme.
		</t>
		<t> 
			Flow control is directional. The client and server independently advertise their 
			flow control preference. It MAY be declared by the receiver and MUST be heeded by the sender.
		</t>
		<t> 
			Flow control can be OFF or ON. It is OFF if no flow control is advertised by a receiver, or
			if it declares "infinite" credit to the sender.
		</t>
		<t> 
			HTTP 2.0 should only standardize the format of the window update message 
			and its semantics. In particular, the algorithms used by the receiver to 
			decide when to send window update messages, and how much to update the window 
			by, are not mandated in the spec. The draft should, however, provide some illustrative examples. 
		</t>
	</list>
	</t>
   
		<t> 
			NOTE: Whether flow control operates on a per-stream basis, on a 
			per-session (per-TCP connection) basis or on both a per-stream and a per-session
			basis is TBD. 
		</t>
		<t> 
			The spec will not define the algorithms the sender will use to manage priorities 
			among streams and to minimize head of the line blocking. This is included for 
			completeness, but is essentially independent of flow-control. 
		</t>

</section>



    <section title="Acknowledgements">
      <t>
   This document was produced using the xml2rfc tool <xref target="RFC2629"/>.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC2616;
      <?rfc include='reference.I-D.ietf-httpbis-p1-messaging.xml'?>
      <?rfc include='reference.I-D.ietf-httpbis-p2-semantics.xml'?>
   </references>

   <references title="Informative References">
      &RFC2629;
      &RFC6455;
      <?rfc include='reference.I-D.mbelshe-httpbis-spdy.xml'?>
      <?rfc include='reference.I-D.montenegro-httpbis-speed-mobility.xml'?>
      <?rfc include='reference.I-D.tarreau-httpbis-network-friendly.xml'?>
   </references>
  </back>
</rfc>