- From: Scott Mitchell <scott.k.mitch1@gmail.com>
- Date: Tue, 17 Jan 2017 12:13:03 -0800
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Benedikt Christoph Wolters <benedikt.wolters@rwth-aachen.de>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAFn2buCx63fxPoM34MxATSSvrAznsob_tuamM1Zv9OJs1-ys1Q@mail.gmail.com>
On Tue, Jan 17, 2017 at 10:35 AM, Scott Mitchell <scott.k.mitch1@gmail.com> wrote: > > > On Tue, Jan 17, 2017 at 10:25 AM, Cory Benfield <cory@lukasa.co.uk> wrote: > >> >> On 17 Jan 2017, at 18:16, Scott Mitchell <scott.k.mitch1@gmail.com> >> wrote: >> >> Thanks for responses everyone. There seems to be recognition that the >> specification lacks clarity but there also seems to be momentum behind >> "Option 1". >> >> This leads to the practical concern of bounding the amount of memory >> committed to streams in this state. SETTINGS_MAX_CONCURRENT_STREAMS limits >> number of streams in "open" or "half-closed", but the specification doesn't >> (to my knowledge) define a way to limit the number of "reserved" streams or >> "idle"/"closed" streams which have had only PRIORITY frames exchanged. The >> specification allows for implementations to discard PRIORITY more or less >> at their discretion [3], but limiting "reserved" streams is another issue. " >> SETTINGS_ENABLE_PUSH" is limited to 0 or 1 [4] so there is no way for a >> client to advertise how many "reserved" streams it is willing to accept. >> What are the practical approaches folks have taken to address these issues? >> >> [3] https://tools.ietf.org/html/rfc7540#section-5.3.4 >> > The retention of priority information for streams that are not counted >> toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a >> large state burden for an endpoint. Therefore, the amount of >> prioritization state that is retained MAY be limited. >> [4] https://tools.ietf.org/html/rfc7540#section-6.5.2 >> >> > The initial value is 1, which indicates that server push is permitted. Any value other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type PROTOCOL_ERROR. >> >> >> SETTINGS_MAX_CONCURRENT_STREAMS is used to limit the number of pushed >> streams. >> >> The key thing to understand is that there are *two* values of >> SETTINGS_MAX_CONCURRENT_STREAMS on each connection: one set by the >> client and one set by the server. The one set by the server limits the >> number of client-initiated streams there may be (that is, streams initiated >> by HEADERS frames). The one set by the client limits the number of >> server-initiated streams there may be (that is, streams initiated by >> PUSH_PROMISE frames). >> >> This is laid out explicitly in RFC 7540 Section 8.2.2: >> > > Ahh yes I forgot about this. Thanks for reminding me. > > I recall where my confusion stems from. Section 5.1.2 contradicts the statements in Section 8.2.2 you referenced. Section 5.1.2 explicitly states that "reserved" streams do not count toward SETTINGS_MAX_CONCURRENT_STREAM S [5]. [5] https://tools.ietf.org/html/rfc7540#section-5.1.2 > Streams that are in the "open" state or in either of the "half-closed" states count toward the maximum number of streams that an endpoint is permitted to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the "reserved" states do not count toward the stream limit. > Any thoughts on limiting the stream priority? > > >> >> > A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit >> > the number of responses that can be concurrently pushed by a server. >> > Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables >> > server push by preventing the server from creating the necessary >> > streams. This does not prohibit a server from sending PUSH_PROMISE >> > frames; clients need to reset any promised streams that are not >> > wanted. >> >> Cory >> >> >
Received on Tuesday, 17 January 2017 20:13:39 UTC