Ignore:
Timestamp:
19/01/13 00:18:13 (10 years ago)
Author:
martin.thomson@…
Message:

Adding flow control principles.

Location:
draft-ietf-httpbis-http2/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html

    r2125 r2127  
    406406  }
    407407  @bottom-center {
    408        content: "Expires July 20, 2013";
     408       content: "Expires July 22, 2013";
    409409  }
    410410  @bottom-right {
    … …  
    447447      <meta name="dct.creator" content="Melnikov, A.">
    448448      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest">
    449       <meta name="dct.issued" scheme="ISO8601" content="2013-01-16">
     449      <meta name="dct.issued" scheme="ISO8601" content="2013-01-18">
    450450      <meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
    451451      <meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
    … …  
    467467            </tr>
    468468            <tr>
    469                <td class="left">Expires: July 20, 2013</td>
     469               <td class="left">Expires: July 22, 2013</td>
    470470               <td class="right">Google, Inc</td>
    471471            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">January 16, 2013</td>
     490               <td class="right">January 18, 2013</td>
    491491            </tr>
    492492         </tbody>
    … …  
    521521         in progress”.
    522522      </p>
    523       <p>This Internet-Draft will expire on July 20, 2013.</p>
     523      <p>This Internet-Draft will expire on July 22, 2013.</p>
    524524      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    525525      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    569569                  </ul>
    570570               </li>
    571                <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.5">Data flow</a></li>
     571               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#flowcontrol">Stream Flow Control</a><ul>
     572                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#fc-principles">Flow Control Principles</a></li>
     573                     <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#fc-basic">Basic Flow Control Algorithm</a></li>
     574                  </ul>
     575               </li>
    572576               <li><a href="#rfc.section.3.6">3.6</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.6">Control frame types</a><ul>
    573577                     <li><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#SYN_STREAM">SYN_STREAM</a></li>
    … …  
    934938         There is no reason to send a RST_STREAM for each frame in succession).
    935939      </p>
    936       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;Data flow
    937       </h2>
    938       <p id="rfc.section.3.5.p.1">Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must
    939          intelligently interleave data messages for concurrent sessions.
    940       </p>
     940      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="flowcontrol" href="#flowcontrol">Stream Flow Control</a></h2>
     941      <p id="rfc.section.3.5.p.1">Multiplexing streams introduces contention for access to the shared TCP connection. Stream contention can result in streams
     942         being blocked by other streams. A flow control scheme ensures that streams do not destructively interfere with other streams
     943         on the same TCP connection.
     944      </p>
     945      <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="fc-principles" href="#fc-principles">Flow Control Principles</a></h3>
     946      <p id="rfc.section.3.5.1.p.1">Experience with TCP congestion control has shown that algorithms can evolve over time to become more sophisticated without
     947         requiring protocol changes. TCP congestion control and its evolution is clearly different from HTTP/2.0 flow control, though
     948         the evolution of TCP congestion control algorithms shows that a similar approach could be feasible for HTTP/2.0 flow control.
     949      </p>
     950      <p id="rfc.section.3.5.1.p.2">HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms without requiring protocol changes.
     951         The following principles guide the HTTP/2.0 design:
     952      </p>
     953      <ol>
     954         <li>Flow control is hop-by-hop, not end-to-end.</li>
     955         <li>Flow control is based on window update messages. Receivers advertise how many octets they are prepared to receive on a stream.
     956            This is a credit-based scheme.
     957         </li>
     958         <li>Flow control is directional with overall control provided by the receiver. A receiver MAY choose to set any window size that
     959            it desires for each stream [[TBD: ... and for the overall connection]]. A sender MUST respect flow control limits imposed
     960            by a receiver. Clients, servers and intermediaries all independently advertise their flow control preferences as a receiver
     961            and abide by the flow control limits set by their peer when sending.
     962         </li>
     963         <li>Flow control can be disabled by a receiver. A receiver can choose to either disable flow control, or to declare an infinite
     964            flow control limit. [[TBD: determine whether just one mechanism is sufficient, and then which alternative]]
     965         </li>
     966         <li>HTTP/2.0 standardizes only the format of the window update message (<a href="#WINDOW_UPDATE" title="WINDOW_UPDATE">Section&nbsp;3.6.8</a>). This does not stipulate how a receiver decides when to send this message or the value that it sends. Nor does it specify
     967            how a sender chooses to send packets. Implementations are able to select any algorithm that suits their needs. An example
     968            flow control algorithm is described in <a href="#fc-basic" title="Basic Flow Control Algorithm">Section&nbsp;3.5.2</a>.
     969         </li>
     970      </ol>
     971      <p id="rfc.section.3.5.1.p.3">Implementations are also responsible for managing how requests and responses are sent based on priority; choosing how to avoid
     972         head of line blocking for requests; and managing the creation of new streams. Algorithm choices for these could interact with
     973         any flow control algorithm.
     974      </p>
     975      <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="fc-basic" href="#fc-basic">Basic Flow Control Algorithm</a></h3>
     976      <p id="rfc.section.3.5.2.p.1">This section describes a basic flow control algorithm. This algorithm is provided as an example, implementations can use any
     977         algorithm that complies with flow control requirements.
     978      </p>
     979      <p id="rfc.section.3.5.2.p.2">[[Algorithm TBD]]</p>
    941980      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;Control frame types
    942981      </h2>
    … …  
    19832022      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;Acknowledgements
    19842023      </h1>
    1985       <p id="rfc.section.9.p.1">Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the design and evolution of SPDY:
    1986          Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe
    1987          Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton.
    1988       </p>
     2024      <p id="rfc.section.9.p.1">This document includes substantial input from the following individuals: </p>
     2025      <ul>
     2026         <li>Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe
     2027            Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors).
     2028         </li>
     2029         <li>Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)</li>
     2030         <li>William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon, Rob Trace (Flow control principles)</li>
     2031         <li>Mark Nottingham and Julian Reschke</li>
     2032      </ul>
    19892033      <h1 id="rfc.references"><a href="#rfc.section.10" id="rfc.section.10">10.</a> Normative References
    19902034      </h1>
    … …  
    20802124      <p id="rfc.section.A.1.p.5">Added section on starting HTTP/2.0, including upgrade mechanism.</p>
    20812125      <p id="rfc.section.A.1.p.6">Removed unused references.</p>
     2126      <p id="rfc.section.A.1.p.7">Added flow control principles (<a href="#fc-principles" title="Flow Control Principles">Section&nbsp;3.5.1</a>) based on &lt;<a href="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01">http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01</a>&gt;.
     2127      </p>
    20822128      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2>
    20832129      <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p>

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml

    r2125 r2127  
    431431      </section>
    432432
    433       <section title="Data flow">
    434 <t>Because TCP provides a single stream of data on which HTTP/2.0 multiplexes multiple logical streams, clients and servers must intelligently interleave data messages for concurrent sessions.</t>
    435       </section>
     433<section anchor="flowcontrol" title="Stream Flow Control">
     434<t>
     435  Multiplexing streams introduces contention for access to the shared TCP connection.  Stream
     436  contention can result in streams being blocked by other streams.  A flow control scheme ensures
     437  that streams do not destructively interfere with other streams on the same TCP connection.
     438</t>
     439
     440<section anchor="fc-principles" title="Flow Control Principles">
     441<t>
     442  Experience with TCP congestion control has shown that algorithms can evolve over time
     443  to become more sophisticated without requiring protocol changes.  TCP congestion control and its
     444  evolution is clearly different from HTTP/2.0 flow control, though the evolution of TCP congestion
     445  control algorithms shows that a similar approach could be feasible for HTTP/2.0 flow control.
     446</t>
     447<t>
     448  HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms
     449  without requiring protocol changes.  The following principles guide the HTTP/2.0 design:
     450  <list style="numbers">
     451    <t>
     452      Flow control is hop-by-hop, not end-to-end.
     453    </t>
     454    <t>
     455      Flow control is based on window update messages.  Receivers advertise how many octets they are
     456      prepared to receive on a stream.  This is a credit-based scheme.
     457    </t>
     458    <t>
     459      Flow control is directional with overall control provided by the receiver.  A receiver MAY
     460      choose to set any window size that it desires for each stream [[TBD: ... and for the overall
     461      connection]].  A sender MUST respect flow control limits imposed by a receiver.  Clients,
     462      servers and intermediaries all independently advertise their flow control preferences as a
     463      receiver and abide by the flow control limits set by their peer when sending.
     464    </t>
     465    <t>
     466      Flow control can be disabled by a receiver.  A receiver can choose to either disable flow
     467      control, or to declare an infinite flow control limit.  [[TBD: determine whether just one
     468      mechanism is sufficient, and then which alternative]]
     469    </t>
     470    <t>
     471      HTTP/2.0 standardizes only the format of the <xref target="WINDOW_UPDATE">window update
     472      message</xref>.  This does not stipulate how a receiver decides when to send this message or
     473      the value that it sends.  Nor does it specify how a sender chooses to send packets.
     474      Implementations are able to select any algorithm that suits their needs.  An example flow
     475      control algorithm is described in <xref target="fc-basic"/>.
     476    </t>
     477  </list>
     478</t>
     479<t>
     480  Implementations are also responsible for managing how requests and responses are sent based on
     481  priority; choosing how to avoid head of line blocking for requests; and managing the creation of
     482  new streams.  Algorithm choices for these could interact with any flow control algorithm.
     483</t>
     484
     485</section>
     486<section anchor="fc-basic" title="Basic Flow Control Algorithm">
     487<t>
     488  This section describes a basic flow control algorithm.  This algorithm is provided as an example,
     489  implementations can use any algorithm that complies with flow control requirements.
     490</t>
     491<t>
     492  [[Algorithm TBD]]
     493</t>
     494</section>
     495</section>
    436496
    437497      <section title="Control frame types">
    … …  
    13131373
    13141374<section title="Acknowledgements">
    1315   <t>
    1316     Prior to being used as the basis for HTTP/2.0, the following individuals contributed to the
    1317     design and evolution of SPDY: Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa
    1318     Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin
    1319     Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton.
     1375  <t>This document includes substantial input from the following individuals:
     1376  <list style="symbols">
     1377    <t>
     1378      Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache,
     1379      William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad,
     1380      Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY contributors).
     1381    </t>
     1382    <t>
     1383      Gabriel Montenegro and Willy Tarreau (Upgrade mechanism)
     1384    </t>
     1385    <t>
     1386      William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon,
     1387      Rob Trace (Flow control principles)
     1388    </t>
     1389    <t>
     1390      Mark Nottingham and Julian Reschke
     1391    </t>
     1392  </list>
    13201393  </t>
     1394
    13211395</section>
    13221396</middle>
    … …  
    15431617</t>
    15441618<t>
    1545   Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
     1619  Changed INTERNAL_ERROR on GOAWAY to have a value of 2 <eref
     1620  target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
    15461621</t>
    15471622<t>
    … …  
    15531628<t>
    15541629  Removed unused references.
     1630</t>
     1631<t>
     1632  Added <xref target="fc-principles">flow control principles</xref> based on <eref
     1633  target="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01"/>.
    15551634</t>
    15561635</section>
Note: See TracChangeset for help on using the changeset viewer.